Glances: a cross-platform system monitor that also speaks HTTP, MCP and Python

What Glances solves, and who actually needs it

Most monitoring tools assume one operating system. Glances does not. The README describes it as an open-source, cross-platform system monitoring tool for GNU/Linux, BSD, macOS and Windows, and pyproject.toml classifies it as Operating System :: OS Independent with Python 3.10 through 3.14 supported. That combination is the reason it exists: a single Python package that reports CPU, memory, disk, network, processes, logged-in users, temperatures, voltages and fan speeds, plus container state for Docker and LXC.

The audience follows from that. A sysadmin with a mixed fleet gets the same dashboard on every host. A developer who wants a quick look at a remote machine can run it over SSH or point a browser at it. Someone writing automation can skip the dashboard entirely and consume the REST API or the Python API. The README also notes that AI assistants such as Claude and Cursor can query Glances through a built-in MCP server, which is a newer surface aimed at tool-using agents rather than humans.

What it is not is a metrics platform. There is no retention, no alerting engine and no query language in the documentation. Glances observes the present moment and can push that moment somewhere else.

The plugin architecture behind the dashboard

Glances is built from plugins. The README states it is based on an open architecture where developers can add new plugins or export modules, and the Python API exposes those plugins by name. Calling gl.cpu returns a dictionary with fields such as total, user, system, idle, iowait, cpucore and ctx_switches. Calling gl.network returns a mapping keyed by interface name, so wlp0s20f3 and veth33b370c are separate entries rather than one merged number.

That structure explains the rest of the product. The TUI, the web UI, the REST API, the XML-RPC interface and the stdout exporters all read from the same plugin objects, which is why a field available in the terminal is normally available over HTTP. Fields that return lists, such as network interfaces or processes, are addressed by name instead of by index. A helper such as gl.auto_unit converts a raw byte count into a human string like 11.6G, so the formatting logic is reusable outside the curses interface.

The dependency list is deliberately small: defusedxml, packaging, psutil, jinja2, plus windows-curses on Windows and shtab elsewhere. Everything else, from GPU support to sensors, smart, raid, snmp, wifi and the web stack, sits behind optional extras in pyproject.toml. If you install only the base package, the dashboard works but the optional plugins will not.

Installing Glances and taking a first reading

The project is distributed on PyPI, so the base install is a single pip command. Use a virtual environment unless you want Glances on the system interpreter.

python3 -m venv .venv
. .venv/bin/activate
pip install glances

After that, running the bare command starts the standalone terminal interface. The README gives exactly this invocation, and the result is the standard dashboard with CPU, memory, disk and network panels.

glances

For a remote or browser-based view, start the web server. The README states that the web interface listens on port 61208 and that the same process exposes an HTTP REST API.

glances -w

Open http://<ip>:61208 in a browser. If you want an AI assistant to query the same instance, add the MCP flag; the README says the MCP endpoint uses SSE transport at http://<ip>:61208/mcp/sse.

glances -w --enable-mcp

For scripting, the stdout modes are the quickest path. The README shows that --stdout takes a comma-separated field list and prints one line per refresh, and that --stdout-csv emits a header row followed by timestamped rows.

glances --stdout cpu.user,mem.used,load
glances --stdout-csv now,cpu.user,mem.used,load

There is also --stdout-json, which the README notes does not support the attribute selector because the output must remain a valid JSON object. A --fetch mode prints a one-shot summary instead of a live dashboard. If you would rather embed the data in Python, import the API module and read plugins directly.

from glances import api
gl = api.GlancesAPI()
print(gl.cpu.get("total"))
print(gl.auto_unit(gl.mem.get("used")))

Where Glances stops being the right tool

Glances has no storage layer. The README lists exports to files, CSV, external time/value databases and STDOUT, but the tool itself keeps only what it needs to draw the current screen. If a process spikes at 03:00 and you were not watching, the default setup will not tell you. Anything resembling history or alerting has to come from the export target or from a separate system scraping the REST API.

Plugin coverage is uneven by design. The base install pulls in psutil and little else; sensors, GPU, smart, raid, snmp and wifi live in optional extras. On a platform where a given data source is unavailable, the corresponding panel is empty rather than wrong, which is easy to misread as a healthy machine. Verify per platform before you rely on a panel.

The interface is also a curses application. On Windows that means the windows-curses dependency, and terminal behaviour differs from a native Windows console tool. For a fleet of identical Linux servers where you already run a full agent, adding Glances mainly adds a second thing to keep patched.

Finally, remote monitoring means opening a port. The README does not document authentication or transport security for the web server or the REST API, so exposing port 61208 to an untrusted network is a decision the documentation does not help you make.

Glances against htop and against a full metrics stack

The README positions Glances as a top/htop alternative, and the difference is scope rather than speed. htop is a local process viewer: it shows processes and resource bars for the machine you are sitting on, and it is excellent at that one job. Glances shows the same class of information but adds remote client/server mode over terminal, web or API, container awareness for Docker and LXC, and an export path to external databases. If you never leave the local machine and never need the data elsewhere, htop is the smaller tool and there is no reason to replace it.

The other comparison is with a time-series monitoring system. Those systems are built around retention and querying: an agent ships samples to a store, and you graph and alert over weeks. Glances deliberately does not do that. It gives you a live view and a way to push samples out. The practical arrangement is to run Glances where you want the interactive view and the REST endpoint, and let it export into the time-series system you already operate. Choosing Glances as a replacement for that system will leave you without history.

Between the two, the deciding question is whether you need to look at a machine now or reason about a machine over time.

Maintenance, licensing and what upgrades cost

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v4.5.6 on 2026-08-01, v4.5.5 on 2026-06-13 and v4.5.4 on 2026-04-19. For an operator, that cadence means upgrades arrive often enough that pinning a version is worthwhile, especially since optional extras pull in third-party packages for sensors, GPU and container support.

On licensing, pyproject.toml declares license = "LGPL-3.0-only", while the repository carries a COPYING file, a LICENSES directory and REUSE tooling in the dev dependencies. The GitHub metadata reports the licence as NOASSERTION, so the machine-readable classification and the project's own declaration disagree. Read COPYING and the LICENSES directory before you redistribute Glances inside a product; LGPL terms differ from permissive licences in ways that matter for bundling, and this article is not legal advice.

Upgrade risk is concentrated in the optional extras and in anything that consumes the REST or MCP surface. The Python API is a stable-looking interface, but plugins gain and lose fields over time, and code that reads gl.cpu["total"] is coupled to that field name. Pin the version in your automation and read NEWS.rst before bumping.

Editorial conclusion

Adopt Glances when you want one tool that behaves the same on Linux, BSD, macOS and Windows, and when you need a terminal dashboard, a browser view and a REST endpoint without deploying an agent stack. Skip it if you need durable metric storage and alerting; Glances exports to time/value databases but does not store history itself, so pair it with a real time-series system. Before rolling it out, verify that the plugins you care about report data on your platform, check the LGPL-3.0-only terms against your distribution plans, and confirm the REST and MCP surfaces are what your clients expect.

Frequently asked questions

Official sources

1. Issues
2. nicolargo/glances on GitHub
3. Project website
4. README
5. Releases