This Glances server monitoring review is a source and documentation review based on the GitHub repository metadata, README, release notes, and open issues captured on 8 August 2026. The evidence includes no local installation or runtime testing, so claims from the repository are attributed to its maintainers and should be confirmed in your own environment before you rely on them.

Answer in brief

Glances is worth evaluating if you want a single open-source tool that combines an interactive terminal dashboard, a web interface, a REST API, and exports to time-series databases, and if you treat it as a monitoring toolkit rather than a complete observability platform. It is actively maintained: the latest release, v4.5.6, was published on 1 August 2026, and the repository showed 33,269 stars and 1,780 forks at the time of this snapshot. The same release series has shipped several security fixes that change web-server behavior, so before production you should review the 4.5.x release notes and configure authentication, allowed hosts, and CORS explicitly.

Key facts at a glance

What Glances is

Glances is a cross-platform system monitor written in Python. The README describes it as an eye on your system and a top/htop alternative for GNU/Linux, BSD, macOS, and Windows. According to the README it reports CPU, memory, disk, and network usage, running processes, logged-in users, temperatures, voltages, fan speeds, and container metrics, with support for container management systems such as Docker and LXC, plus optional Podman and LXD dependencies.

The project offers more than a single terminal screen:

• Terminal UI: run glances for an interactive full-screen dashboard.
• Web server and API: glances -w serves a web dashboard on port 61208 and exposes an HTTP/RESTful API.
• MCP server: add --enable-mcp (available in Glances 4.5.1 and higher per the README) so AI assistants can query it over an SSE endpoint at /mcp/sse.
• Raw output: --stdout, --stdout-csv, and --stdout-json for scripts, plus --fetch for a quick look at a machine.
• Multi-server browser: --browser detects Glances servers on the network or in configuration.
• Python library: the glances.api module gives programmatic access to plugins and their fields.
• Exports: CSV/JSON files; databases such as InfluxDB, Elasticsearch, PostgreSQL/TimeScale, Cassandra, ClickHouse, CouchDB, OpenTSDB, Prometheus, StatsD, Riemann, and Graphite; brokers such as RabbitMQ/ActiveMQ, NATS, ZeroMQ, and Kafka; plus a RESTful endpoint.

The export layer is the part that matters most for operations. Glances is not described by its maintainers as an alerting or long-term storage platform, so retention and alerting still need to come from the export target or another system.

Who should consider Glances

Consider Glances if you manage a small number of Linux or BSD servers and want a richer terminal view than top or htop, including per-process data, disk I/O, sensors, and containers, in one place. It is also a reasonable fit if you want a lightweight web view and REST access without running a separate monitoring server, or if you already have a time-series backend and want an exporter with many integration options. The MCP support is a recent addition, so teams experimenting with AI assistants querying host state have a built-in path rather than a custom bridge.

If you are on macOS or Windows alongside Linux, the same tool can be used everywhere, but check the platform caveats below first.

Where the limits show up

• No full observability platform: the README does not describe built-in historical storage, multi-tenant dashboards, or an alert manager, so long-term retention and alerting must come from the export layer or another product.
• Server-mode export gap: issue #1527, open since 2019, reports that a Glances server cannot export data while running in server mode and that a client connection is needed. If you expected the daemon to archive metrics on its own, plan around this gap.
• Windows gaps: issue #3265 reports that Glances does not read temperatures on Windows, and issue #3046 reports slow web-server startup and reloads on Windows 11. If Windows temperature coverage or web performance matters, verify on your actual hardware.
• Thin hardware coverage: open requests include ECC RAM error reporting (#3282) and Xen hypervisor domain statistics (#2184); neither is a confirmed feature.
• Dependency churn: SNMP support relies on pysnmp-lextudio, which the upstream project reports as deprecated, and issue #2874 tracks the migration. This is the kind of dependency that can silently break a packaged install.

Maintenance signals

Activity is strong. The repository was created in December 2011, the default branch is develop, the last push recorded at snapshot time was 7 August 2026, and releases have arrived regularly: v4.5.2 on 14 March 2026, v4.5.3 on 29 March 2026, v4.5.4 on 19 April 2026, v4.5.5 on 13 June 2026, and v4.5.6 on 1 August 2026.

The release notes are the maintenance signal worth reading before you adopt it. The 4.5.x series contains multiple security patches, several with breaking changes. v4.5.2 alone lists eight CVEs and breaking changes covering host-header validation, restrictive CORS defaults, redaction of sensitive API fields, credential forwarding in browser mode, shell escaping in action templates, and parameterized DuckDB DDL. Later releases continued patching command injection, DNS rebinding, SSRF, and credential-leak paths. The maintainers are fixing issues quickly; the tradeoff is that production users must track releases and re-test configuration after upgrades.

Deployment concerns to check before production

• Version pinning and upgrade testing: with security patches across 4.5.2 through 4.5.6, pin to a tested release and re-read the release notes before every upgrade, because configuration behavior can change between patches.
• Authentication defaults: per the v4.5.2 notes, the REST API still runs without authentication by default for private-network deployments, and Glances now prints a startup warning when no password or API token is configured. If the interface can be reached beyond localhost, authentication is on you.
• Host validation: v4.5.2 enforced host-header validation on the built-in web server, so requests with a non-matching Host header are rejected with HTTP 400 by default. Access through a reverse proxy, custom hostname, or non-loopback IP requires allowed hosts to be declared via the allowed_hosts key in the [outputs] section of glances.conf. The v4.5.2 notes add that this was already required for the MCP server since 4.5.1.
• CORS: the default policy is now restrictive, and custom web front-ends on another origin need cors_origins configured in glances.conf.
• Network exposure: the web UI, REST API, and MCP SSE endpoint listen on port 61208. In web-server mode the README’s Docker example publishes ports 61208-61209, mounts the Docker socket read-only, and uses the host PID namespace, so restrict who can reach the service and understand what the container can observe.
• Packaging differences: the README recommends pip inside a virtual environment or the Docker images, and the maintainers do not recommend distribution packages because they may lag and enable only basic plugins. The Debian package reportedly no longer includes the JavaScript static files used by the web interface, and in Glances 4 the static path is configurable. Choose pip/venv, uvx, pipx, or Docker unless you know your distro package is current.
• Python requirement: Glances 4.x requires Python 3.10 or higher; Python 2 users would need Glances 3.4.x.
• Feature extras: the base install has no web dependencies. Web, GPU, containers, sensors, RAID, SNMP, MCP, and export modules are extras, so choose ‘glances[web]’, ‘glances[all]’, or the specific extras you need and quote the brackets in shell.

Evaluation questions before you adopt it

• Do you need historical metrics and alerting, or just a better view of a few machines right now? If you need history and alerting, pair Glances with an export target or choose a purpose-built time-series stack.
• Will the web, API, or MCP endpoint be reachable beyond localhost? If yes, plan authentication, allowed hosts, CORS, TLS through a reverse proxy, and network access controls before the first deploy.
• Do you need Windows temperatures or other hardware sensors? Confirm on your actual hardware, because the repository shows gaps.
• Does your stack depend on a less common exporter such as Cassandra, OpenTSDB, or Riemann? Verify that the extra dependency is current for your exporter version.
• Who owns upgrades? Glances releases security fixes frequently, and if nobody owns upgrades and configuration re-tests, a fleet-wide default install will drift.

Verdict

For a small operation that wants one actively maintained open-source tool for interactive and web-based system visibility, Glances is a strong candidate, provided you treat the 4.5.x release notes as part of the upgrade process and lock down any exposed interface. For teams that need long-term metrics, alerting, and dashboards at scale, it is better used as a data source behind an existing time-series backend than as the whole monitoring platform.

Sources

• Glances repository (nicolargo/glances): repository metadata, README, topics, and open issues
• Glances v4.5.6 release notes
• Glances v4.5.5 release notes
• Glances v4.5.2 release notes with breaking security changes
• Issue #1527: export while in server mode
• Issue #3046: Windows 11 web server slow startup and UI
• Issue #3265: Windows temperature monitoring gap
• Issue #2874: pysnmp-lextudio dependency migration
• Glances documentation on Read the Docs

If you need help putting this into production

I’m Xiang Peng at XP812. If you are evaluating Glances or another monitoring tool for Linux servers, I can help with deployment, hardening the web and API exposure, planning the upgrade path, wiring exporters to your existing storage, and troubleshooting performance issues. That is the kind of work that turns a promising open-source project into something you can rely on in production.