unsubbed.co

Glances

Cross-platform curses-based system monitoring tool written in Python.

Open-source server monitoring, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

  • What it is: Open-source cross-platform system monitoring tool — think htop with a web UI, REST API, multi-server remote mode, and an MCP server baked in since v4.5.1 [1][2].
  • Who it’s for: Self-hosters, sysadmins, and developers who want real-time visibility into one or more servers without deploying a full monitoring stack. Also anyone paying Datadog prices for basic “is this server healthy?” use cases.
  • Cost savings: Datadog infrastructure monitoring starts at $15/host/month. New Relic charges $0.30/GB ingested. Glances is $0 plus the server you already own.
  • Key strength: Three interfaces from one binary — terminal, web browser, REST API — plus export to InfluxDB, Elasticsearch, Grafana, and a dozen other targets. You get more monitoring surface than htop without touching Prometheus [1][2][README].
  • Key weakness: Real-time only by default. No built-in alerting, no historical trending UI, no managed cloud fallback. It’s a monitoring agent, not a monitoring platform [README].

What is Glances

Glances is a cross-platform system monitoring tool written in Python. It started as a terminal htop alternative that surfaces more metrics than top, then grew into something more interesting: a unified monitoring agent that simultaneously runs in a terminal, serves a web interface on port 61208, exposes a full REST API, and — as of version 4.5.1 — speaks MCP so AI assistants can query your server stats directly [README].

The GitHub description is honest: “A top/htop alternative for GNU/Linux, BSD, Mac OS and Windows operating systems.” The homepage calls it “an eye on your system” [README][homepage]. Neither phrase captures the differentiator. What makes Glances more than a process viewer is the combination of immediacy and connectivity: run one command and you get a color-coded terminal dashboard, a browser-accessible UI, and a REST API that Grafana, InfluxDB, or your own scripts can query.

The project is maintained by Nicolas Garault with 340+ contributors and sits at 32,078 GitHub stars [README]. It uses the psutil library as its primary data source, which accounts for its cross-platform reach — the same Python code runs on Linux, FreeBSD, macOS, and Windows [1]. The plugin architecture lets the community extend it to GPUs, RAID arrays, SMART disk data, SNMP devices, Docker/Podman containers, and WiFi stats without touching the core [README].

For remote monitoring, Glances runs in client/server mode where one machine acts as the server and another connects as the client — through a terminal, the web UI, or the API [2]. That’s what separates it from htop: you can monitor a fleet of servers from a single terminal session, with no agent infrastructure beyond Glances itself.


Why people choose it over htop and paid monitoring SaaS

Three use cases drive most Glances adoption.

You want more than htop without running a monitoring stack. htop is excellent for local process management, but it can’t monitor remote machines natively and has no export path [3]. The SaaSHub comparison of htop vs Glances is blunt about this: “Limited Remote Monitoring — htop does not natively support remote monitoring of systems” and “No Built-in Logging — htop does not have functionality for logging or saving historical data” [3]. Glances covers the same CPU/memory/process territory and adds disk I/O, network interfaces, sensors, containers, and export to InfluxDB or Elasticsearch — all from the same binary [1][2].

You need a web UI without deploying a full stack. If you’re on a server with no persistent terminal session, glances -w gives you a browser-accessible dashboard at port 61208 with zero additional setup. No Prometheus configuration, no node_exporter, no Grafana [1][2]. TecMint’s review treats the web interface and CLI as two equally first-class interfaces, not as a web interface bolted on as an afterthought [1].

You’re paying Datadog or New Relic for something Glances handles. Datadog’s infrastructure tier runs $15–$34/host/month. For a team running 10 servers, that’s $150–$340/month — $1,800–$4,080/year — for metric collection and visualization. Glances collects the same host-level metrics for $0. The gap is alerting, APM, and long-term retention — Glances doesn’t provide those natively — but if you’re paying Datadog and only using it to answer “is this server healthy right now?”, the math is hard to defend.

The MCP angle is real. Running glances -w --enable-mcp exposes an SSE MCP endpoint at http://<ip>:61208/mcp/sse that Claude, Cursor, and Windsurf can query directly [README]. Instead of SSHing into a machine to check what’s consuming memory, you ask your AI assistant. Whether that’s a killer feature or a novelty depends on how much of your workflow lives inside AI coding tools, but it’s the only major open-source system monitor with this built in.


Features

Terminal interface:

  • Color-coded alerts: metrics that breach thresholds turn red automatically [1]
  • Hotkey controls for sorting by CPU or memory, toggling disk/network views, filtering log messages [1]
  • --stdout and --stdout-csv modes for piping raw stats to scripts or automation [README]
  • Process list with filtering and sorting [README][1]
  • Quicklook panel for immediate CPU/MEM/LOAD overview [homepage]

Web interface:

  • Browser-accessible at port 61208 via glances -w [1][2]
  • Optional password protection [2]
  • Network browser to discover and display all Glances instances on the local network [README]
  • Same data coverage as the terminal view, accessible from any device

Client/server and remote monitoring:

  • Server mode exposes XML-RPC and RESTful JSON APIs [README]
  • Client mode connects to any remote Glances server via terminal, web, or API [2]
  • --browser flag to auto-discover Glances servers on the network [README]

MCP server (v4.5.1+):

  • Enabled with --enable-mcp flag alongside web mode [README]
  • SSE transport endpoint for AI assistant integration [README]

Export integrations:

  • CSV, InfluxDB, Cassandra, OpenTSDB, StatsD, Elasticsearch, RabbitMQ [README][homepage]
  • PostgreSQL, ClickHouse, MongoDB via plugins [README]
  • Grafana dashboard template included [homepage]

Monitoring coverage:

  • CPU, memory, load average, swap [README][1]
  • Network interfaces and bandwidth [README][1]
  • Disk I/O and filesystem usage [README][1]
  • Running processes and logged-in users [README][1]
  • Temperatures, voltages, fan speeds (sensor plugins) [README][1]
  • RAID arrays and SMART disk health [README]
  • GPU metrics [README]
  • WiFi statistics [README]
  • Docker and Podman container monitoring [README][homepage]
  • SNMP devices [README]
  • IRQ and system alerts [homepage]

Pricing: SaaS vs self-hosted math

Glances has no pricing tiers. It’s free, open source, and imposes no usage limits [README][homepage]. The relevant comparison is against the paid monitoring SaaS tools it displaces.

Datadog:

  • Infrastructure monitoring: $15/host/month (annual) to $23/host/month (on-demand)
  • Log management: $0.10/GB/month ingested, plus retention fees
  • APM: $31/host/month additional

New Relic:

  • Free: 100GB/month data ingest, 1 full-access user
  • Beyond free tier: $0.30/GB ingested per month
  • Full platform seat: $549/user/year

Grafana Cloud:

  • Free tier: 10,000 metrics, 50GB logs, 50GB traces
  • Pro: $8/month base plus usage-based charges

Glances self-hosted:

  • Software: $0
  • Server: already owned, or $5–10/month if you’re adding dedicated infrastructure

Concrete math for a small team on 10 servers:

Datadog Infrastructure at $15/host: $150/month, $1,800/year. Glances: $0. If you want historical data beyond real-time, add InfluxDB + Grafana on an existing VPS — still free. If you add a dedicated $6/month Hetzner VPS for your monitoring stack: $72/year total, vs $1,800 for the Datadog equivalent.

The honest caveat: Glances doesn’t replace Datadog feature-for-feature. Datadog’s value-add is APM, distributed tracing, log aggregation, intelligent alerting, and long-term retention in one managed platform. If you need those, Glances is a piece of the stack, not the whole stack. But if your Datadog usage is “check CPU and memory graphs once a week,” the savings are real.


Deployment reality check

Standalone — under 2 minutes:

pip install glances
glances

If Python is installed, you’re monitoring your local machine immediately [1][2].

Full installation with all plugins:

pip install glances[all]

Or via package managers: apt install glances on Debian/Ubuntu; brew install glances on macOS; yum install glances on RHEL/CentOS after enabling EPEL [1]. Alpine, Arch, and openSUSE have native packages.

Docker:

Official images on Docker Hub (nicolargo/glances) with Alpine-based minimal and Ubuntu-based full variants [README].

Web mode:

glances -w

Web UI at http://<ip>:61208. REST API at the same endpoint. No nginx required to start, though you’ll want a reverse proxy with HTTPS before exposing this outside your local network [2].

MCP mode:

glances -w --enable-mcp

MCP endpoint at http://<ip>:61208/mcp/sse [README].

What can go wrong:

The glances[all] install pulls a long dependency tree. On a minimal production server you may hit missing system libraries for GPU support or sensor reading. The minimal install is stable; the “all” variant occasionally conflicts on older Python versions or stripped-down distributions [1]. Test on a non-production machine first.

Port 61208 with no authentication is open by default. The CloudCone guide flags optional password protection [2], but it’s not on by default. Don’t run glances -w internet-facing without a reverse proxy and auth layer.

Real-time only means no historical data unless you configure an export target. InfluxDB is the most common pairing for time-series retention, but that’s additional setup — a docker-compose file and Grafana configuration on top of Glances.

There’s no built-in alerting. The color-coded thresholds are visual only [1]. Notifications on critical events require wiring in an external system: Grafana Alerting, Alertmanager, or a custom script hitting the REST API.

Realistic time estimates:

  • Local terminal monitoring via pip: under 5 minutes
  • Web mode with basic auth behind nginx: 30–60 minutes
  • Full stack with InfluxDB export and Grafana dashboard: 2–4 hours
  • Non-technical user following a guide: budget a full afternoon

Pros and cons

Pros

  • Free with no restrictions. No seat limits, no tier walls, no license fee for commercial use. Run it on one server or a hundred [README][homepage].
  • Three interfaces from one command. Terminal, web UI, and REST API are built in — no secondary service needed [1][2].
  • Broad metric coverage. CPU, memory, disk, network, processes, sensors, RAID, SMART, GPU, WiFi, containers — more in one agent than most alternatives [README][1].
  • Export to everything. InfluxDB, Elasticsearch, Cassandra, CSV, PostgreSQL, ClickHouse — pick your time-series stack and Glances feeds it [README][homepage].
  • MCP server built-in. AI assistants can query live server metrics without SSH access [README].
  • Cross-platform. Runs on Linux, macOS, Windows, BSD with the same Python codebase [1][2][3].
  • 32,000+ GitHub stars and 340+ contributors — active, not abandoned [README].
  • Color-coded alerts make problems immediately visible without configuration [1].
  • Client/server mode for fleet monitoring with no dedicated agent infrastructure [2].

Cons

  • Real-time only by default. No built-in historical data — you need to configure InfluxDB or similar to retain anything past the current session [README].
  • No built-in alerting. Threshold colors are visual. There’s no notification system, no webhook on critical events, no on-call integration [1].
  • Python runtime dependency. On minimal production servers, some teams prefer a single-binary Go agent for monitoring. Python adds a dependency and occasional version-conflict surface.
  • Web UI is functional, not polished. It’s a terminal view rendered in a browser. Datadog and Grafana it is not [3].
  • No managed cloud option. Self-hosting is the only path. Fine if that’s your preference; a blocker if you want vendor-backed SLAs.
  • License ambiguity in published profile data. The license field in our merged profile returns “NOASSERTION” — the specific license terms weren’t cleanly parsed. The project is clearly open source with a freely available codebase, but verify at the GitHub repository before embedding in a commercial product.
  • Getting to full alerting still requires external tooling. Glances alone doesn’t page you at 3am. Reaching Datadog-equivalent alerting means adding InfluxDB, Grafana, and Alertmanager — more work than a SaaS signup.

Who should use this / who shouldn’t

Use Glances if:

  • You want immediate visibility into what’s happening on a Linux or macOS server right now, with zero configuration overhead.
  • You run multiple servers and want remote monitoring without deploying a full Prometheus/Grafana stack.
  • You’re paying Datadog or New Relic primarily for basic host-level metrics and the bill is disproportionate to what you actually use.
  • You want to export system metrics to InfluxDB or Elasticsearch as part of a home-built observability stack.
  • You live inside AI coding tools (Claude, Cursor) and want your assistant to be able to check server health via MCP.
  • You’re comfortable in a terminal and want more than htop without a multi-service deployment.

Skip it (use Netdata instead) if:

  • You want beautiful real-time dashboards, automatic anomaly detection, and built-in alerting with optional cloud sync — with no Grafana configuration required.
  • You want a polished monitoring UI that non-engineers can read without training.

Skip it (use Prometheus + Grafana instead) if:

  • You need long-term metric retention, complex multi-condition alerting, and multi-team dashboard access.
  • You’re monitoring a production engineering environment where observability is a first-class concern.
  • You want service-level monitoring, not just host-level stats.

Skip it (stay on Datadog) if:

  • You need APM, distributed tracing, log aggregation, and infrastructure monitoring unified under one SLA.
  • Your compliance requirements demand a vendor-backed monitoring solution.
  • Your engineering team already has Datadog expertise and the monthly cost is justified by the time it saves.

Skip it (use htop) if:

  • You only need local process management on a single machine and you’re comfortable SSHing into each server individually. htop is faster to install and simpler for this specific use case [3].

Alternatives worth considering

  • htop — the obvious comparison. Better for interactive process management: kill, renice, tree view. No web UI, no remote monitoring, no export path. Use htop when debugging a specific runaway process. Use Glances when you want a persistent system overview across multiple machines [3].
  • Netdata — real-time monitoring with genuinely beautiful built-in dashboards, automatic anomaly detection, and optional Netdata Cloud sync. More polished than Glances’ web UI. More opinionated about how you monitor. Free community edition plus paid cloud tier.
  • Prometheus + Node Exporter + Grafana — the standard self-hosted observability stack for engineering teams. More powerful, more flexible, significantly more work to deploy and maintain. Glances is what you reach for when this stack is overkill for your situation.
  • Zabbix — enterprise-grade monitoring with built-in alerting, network device monitoring, and agent-based collection. Substantially more complex than Glances. Better fit for IT infrastructure teams managing heterogeneous environments.
  • Telegraf — InfluxData’s collection agent. More configuration overhead than Glances, but finer-grained control over what gets collected and where it goes. Logical choice if you’re already deep in the InfluxDB stack.
  • Datadog — the commercial benchmark. Full-featured, cloud-managed, expensive at volume. Justified for production engineering teams; hard to justify for solo founders or small teams running a handful of VPS instances.

For a non-technical founder who wants basic server health visibility: the realistic shortlist is Glances vs Netdata. Glances for simplicity and minimal footprint. Netdata for a more polished dashboard without touching Grafana.


Bottom line

Glances occupies a specific and genuinely useful niche: it’s the monitoring tool you reach for when htop isn’t enough and Prometheus is too much. It monitors everything relevant at the host level — CPU, memory, disk, network, containers, sensors, GPU — and surfaces those metrics through a terminal, a web browser, and a REST API simultaneously, then ships the data to whatever time-series stack you’re already running. The MCP integration is a real differentiator for teams that live inside AI tools. What it doesn’t do is replace a full observability platform — there’s no built-in alerting, no historical trending without external storage, and no managed fallback. For a solo founder or small team running a handful of servers and paying nothing for monitoring software, that trade is obvious. For an engineering team with production SLAs and on-call rotations, Glances is a useful agent feeding a larger stack, not the stack itself.


Sources

  1. Ravi Saive, TecMint“Glances: A Powerful Tool for Monitoring Linux Systems” (July 31, 2023). https://www.tecmint.com/glances-linux-monitoring/
  2. James, CloudCone“Glances – A Real-Time Monitoring Tool for Linux” (June 18, 2021). https://cloudcone.com/docs/article/glances-a-real-time-monitoring-tool-for-linux/
  3. SaaSHub“htop VS glances system monitoring — compare differences & reviews”. https://www.saashub.com/compare-htop-vs-glances-system-monitoring

Primary sources:

Features

Integrations & APIs

  • Plugin / Extension System

Mobile & Desktop

  • Mobile App