Glances: one Python process for TUI, web, REST and MCP system monitoring
Glances an Eye on your system. A top/htop alternative for GNU/Linux, BSD, macOS and Windows operating systems.
At a glance
- What is it?
- Glances reads CPU, memory, disk, network, process, sensor and container data through a plugin architecture and republishes it over a terminal UI, a web dashboard, a RESTful API, an MCP server and stdout exports. It is a good fit when you want one tool for local inspection and remote collection, and a poor fit when you need long-term metric storage or alerting.
- Who is it for?
- Adopt Glances if you want a single Python package that gives you an interactive terminal view, a browser dashboard, a RESTful API and an MCP endpoint for AI assistants on GNU/Linux, BSD, macOS or Windows, and you are comfortable with the machine that collects the data also holding it in memory.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Glances fills between top and a full metrics pipeline
Running top or htop answers one question well: what is happening on this machine right now. The moment you need the same numbers from a second host, or from a container, or from a script, or from an AI assistant, you either open another SSH session or you stand up a metrics pipeline. Glances sits in the middle. The README describes it as an open-source cross-platform monitoring tool that covers CPU, memory, disk and network usage, plus running processes, logged-in users, temperatures, voltages and fan speeds, and container monitoring for Docker and LXC. The intended audience is the engineer who wants those numbers available through several front ends without installing several agents. The same process can print a dashboard in a terminal, serve a browser page, answer REST calls, expose an MCP endpoint on Glances 4.5.1 and higher, and stream selected fields to stdout. That last part matters more than it sounds: it means a shell script can consume live metrics without a client library.
Plugin architecture and the four ways data leaves the process
Glances is written in Python and, per the README, uses libraries to grab information from the system. The stated design is an open architecture where developers add new plugins or export modules. That single sentence explains most of the behaviour you will observe: each monitored area is a plugin that produces a dict of fields, and each output channel is a consumer of those dicts. The Python API example in the README makes the shape concrete. Importing glances.api and instantiating GlancesAPI gives you attributes such as gl.cpu, which returns a dictionary with keys like total, user, system, idle, iowait, cpucore and ctx_switches. Calling gl.cpu.get("total") returns a single value, and gl.auto_unit(gl.mem.get("used")) converts a byte count into a human-readable string such as 11.6G. Plugins that return collections are keyed by name: the README shows gl.network.keys() returning interface names like wlp0s20f3 and veth33b370c. The data flow is therefore pull-based and stateless between reads. Nothing in the README describes a persistence layer inside Glances itself. Metrics exist as the current snapshot, and if you want history you send them somewhere else through an export module. That is a deliberate boundary, and it is the line where most adoption decisions get made.
Running the TUI, the web server and the MCP endpoint
Standalone mode is a single command with no arguments: glances. That opens the terminal dashboard shown in the README's summary screenshot. Web mode is glances -w, and the README says to open http://<ip>:61208 in a browser, where a HTTP/Restful API is also exposed. To add the Model Context Protocol server for AI assistants, the command is glances -w --enable-mcp, and the MCP endpoint uses SSE transport at http://<ip>:61208/mcp/sse. The README points to McpApi documentation for client configuration. Service discovery is built in: glances --browser finds Glances servers on the network or defined in the configuration file, and glances -w --browser does the same for the web UI. For scripting, the stdout exporters are the useful part. glances --stdout cpu.user,mem.used,load emits one labelled line per field per refresh, and the README shows load arriving as a nested dict with cpucore, min1, min5 and min15. glances --stdout-csv now,cpu.user,mem.used,load flattens nested keys into columns such as load.min1 and prefixes a timestamp column. glances --stdout-json cpu,mem emits a JSON object per field, and the README notes that attributes are not supported in this mode so the output stays a real JSON object. There is also glances --fetch for a one-shot snapshot, and a legacy XML-RPC client/server mode that the README mentions without documenting further.
What Glances does not do, and where it becomes the wrong tool
Glances holds no history. The README lists export to files, external time/value databases, CSV and direct STDOUT output, which means retention, downsampling and querying are somebody else's problem. If your requirement is a graph of last Tuesday at 03:00, Glances alone will not answer it. The second constraint is the client/server model. In web or client/server mode the monitored host runs a Python process that exposes port 61208, and the README does not describe authentication or transport encryption for that endpoint. Treating 61208 as an internal-only port is a deployment decision you have to make yourself, and the documentation supplied here gives no guidance on it. The third constraint is platform variance. Glances advertises GNU/Linux, BSD, macOS and Windows, but sensors, container runtimes and per-process detail depend on what the host exposes. The README does not publish a per-plugin platform matrix, so the only reliable check is running glances on the target and confirming the plugins you care about return values rather than empty dicts. Finally, the licence metadata reports NOASSERTION. The README does not state a licence identifier, and the repository metadata does not resolve one. If you plan to redistribute Glances inside a product, that is the first thing to clarify with the maintainer, not a detail to assume.
Glances against node_exporter: snapshot tool versus scrape target
The closest functional alternative for Linux fleet monitoring is Prometheus node_exporter. The difference in approach is not cosmetic. node_exporter is a stateless HTTP endpoint that Prometheus scrapes on an interval, and every scraped sample lands in a time-series database with a query language and an alerting layer on top. Glances is an application you look at, with a RESTful API and export modules bolted onto the same process that renders the dashboard. If you already run Prometheus, adding Glances as a second collector duplicates work unless you specifically want the interactive TUI or the MCP endpoint on the same hosts. If you do not run Prometheus and do not want to, Glances gives you the live view and the raw feed with one pip install and no server to operate. The honest framing is that they overlap on data collection and diverge on everything after it. Glances also differs from a shell loop over /proc: the plugin layer normalises field names across operating systems, so cpu.user means the same thing in a script whether the host is Linux or macOS. That normalisation is the actual product, more than any individual metric.
Release cadence, upgrade cost and the developing branch
The repository's default branch is develop, not main, and the last push recorded is 2026-09-10. Recent releases are v4.5.6 on 2026-08-01, v4.5.5 on 2026-06-13 and v4.5.4 on 2026-04-19, which is roughly a six to eight week cadence across the three most recent tags. That pace is fast enough that pinning a version is worth doing if you depend on the RESTful API or the stdout field names, because both are the kind of surface that moves between minor releases. Upgrading is a pip install away, but the cost is not zero: the plugin field set is the API, and a renamed key breaks a script that parses glances --stdout-json cpu,mem. The MCP server is a recent addition, available in Glances 4.5.1 and higher per the README, so anything below that version simply does not have the endpoint regardless of configuration. On the licensing side, the metadata says NOASSERTION, which means you cannot infer terms from the repository listing alone. Read the licence file in the source tree before you ship Glances inside anything, and if the file is ambiguous, ask the maintainer directly. This is a factual gap in the metadata, not a warning about the project's intentions.
Who should install it, and what to check on the first host
Glances earns its place on a workstation or a small set of servers where you want an interactive view and a scriptable feed from the same tool, and where you are willing to run a Python process on each monitored machine. It is also a reasonable choice if you are wiring an AI assistant into live system state, since the MCP server is a documented feature rather than a side project, though it requires --enable-mcp and Glances 4.5.1 or later. It is the wrong tool if your first requirement is retention and alerting, or if you cannot expose port 61208 on an internal network, or if the host is locked down to the point where installing Python packages is a change-control event. The first things to verify on a real host are mundane and specific. Run glances and confirm the plugins you need are populated. Run glances --stdout-json cpu,mem and check that the field names match what your parser expects. Run glances -w --enable-mcp and confirm http://<ip>:61208/mcp/sse responds before pointing an assistant at it. Then decide whether the export target you need is a file, a time/value database or a pipe, because that choice, not the dashboard, determines how much of Glances you actually keep.
Editorial conclusion
Adopt Glances if you want a single Python package that gives you an interactive terminal view, a browser dashboard, a RESTful API and an MCP endpoint for AI assistants on GNU/Linux, BSD, macOS or Windows, and you are comfortable with the machine that collects the data also holding it in memory. Do not adopt it as a replacement for a time-series database and alerting stack, because the documented export targets are files, CSV, stdout and external time/value databases, not a query language or a rule engine. Before rolling it out, verify three things on your own hosts: that the plugins you need actually return data on your platform, that port 61208 is reachable and secured in client/server mode, and that the licence terms in the repository match how you intend to redistribute it, since the metadata reports NOASSERTION rather than a named licence.
Community notes