Glances and the Terminal Dashboard Habit

There is a specific sequence I used to perform, several times a week, on a machine behaving oddly. top, squint at the load average. q. df -h, squint at the filesystems. free -m. iostat -x 2, wait for the second sample because the first one is a lie. iftop, remember it needs sudo, retype it. sensors. docker stats, in a second window. Six tools, four minutes, and by the time I have the last number the first one is stale.

Glances is that sequence collapsed into one screen that updates every two seconds. It is written in Python, it has been quietly excellent for over a decade, and it occupies a specific niche that no dashboard product can touch: it is the thing you run when you have just ssh’d into a machine and want to know what is wrong with it, right now, without opening a browser.

I want to be precise about the niche, because Glances is frequently and wrongly compared against monitoring systems. It stores nothing. It alerts nobody. It is a viewer. Judging it against Prometheus is like judging a torch against the National Grid.

What one screen gets you

Run glances on a busy host and the default layout gives you, simultaneously:

• Load average, per-core CPU broken into user/system/iowait/steal, and a summary bar
• Memory and swap with actual/used/free and the buffers-and-cache breakdown that free makes you squint at
• Per-interface network throughput, up and down, in human units
• Per-disk read and write rates
• Filesystem usage for every mount, with the near-full ones in red
• Temperature and fan sensors, if lm-sensors has anything to say
• Running containers with per-container CPU and memory
• A process list sorted by whatever is currently the constraint
• A warnings log at the bottom recording what has been red recently

That last one is more useful than it sounds. Glances keeps a short in-memory history of threshold crossings, so a CPU spike that happened ninety seconds before you connected is still on the screen. top would have told you nothing.

The automatic sort is the feature that makes it a habit. Glances watches which resource is under pressure and sorts the process list by that resource without being asked. Land on a box that is swapping and the process list is already sorted by memory. Land on one that is thrashing a disk and it is sorted by I/O. This sounds like a gimmick until the first time it puts the answer at the top of the screen before you have finished reading the header.

The colours are consistent throughout: green is fine, blue is careful, magenta is warning, red is critical, and the thresholds are configurable per plugin. Scanning for red is the whole workflow.

Installing it without wrecking your Python

Glances is a Python application, which in 2025 means you should keep it away from your system interpreter. Distro packages exist and are usually a version or two behind. The clean answer is pipx:

1
2
3
4
5
6
7

# Debian/Ubuntu
sudo apt install pipx
pipx install 'glances[web,sensors,containers]'
pipx ensurepath

# Verify
glances --version

The extras matter. Plain pipx install glances gives you the core; the web UI, the sensor plugin and container support each pull their own dependencies and are omitted by default. glances[all] pulls everything including export backends you will never use, which on a Pi is a genuinely slow install.

For a host where you would rather install nothing at all:

1
2
3
4
5
6

docker run --rm -it \
  --pid host \
  --network host \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -e TERM \
  nicolargo/glances:4.3.0.8-full

--pid host is required for the process list to show anything other than Glances itself, which is a mildly comic default failure. -e TERM is required for the curses UI to render correctly, and forgetting it produces a screen full of escape sequences that looks like a hardware fault.

There is a third option that I use more than either: pipx install glances on the one machine I ssh from, and then client-server mode for everything else. More on that below.

The config file

Glances runs perfectly with no config. The two things worth changing are thresholds and plugin selection, in ~/.config/glances/glances.conf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

[global]
refresh=3
history_size=1200

[cpu]
user_careful=60
user_warning=80
user_critical=95
iowait_careful=20
iowait_warning=35
iowait_critical=50

[memory]
careful=60
warning=80
critical=92

[fs]
careful=60
warning=80
critical=90
hide=/snap.*,/var/lib/docker/.*,/run/.*

[diskio]
hide=loop.*,dm-.*

[network]
hide=lo,docker.*,veth.*,br-.*
careful=70
warning=85

[processlist]
nice_warning=-20,-19,-18
cpu_careful=50
cpu_warning=70

[ports]
port_default_gateway=True
refresh=30

[containers]
max_name_size=25
disable=False

The hide lines are the ones that turn Glances from cluttered to readable. A container host has forty veth interfaces, twenty loop devices from snaps and a /var/lib/docker/overlay2 mount per container. Hiding them takes the network section from an unreadable wall to four real interfaces.

Note the iowait thresholds under [cpu], set deliberately low. High iowait at 20% is worth a colour change, because it means the machine is waiting on storage, which is the single most common cause of “this box feels slow” and the one top’s default display buries.

Two useful flags to memorise:

1
2
3
4

glances -1                 # per-CPU rather than aggregate
glances --disable-plugin cloud,irq,folders,raid
glances --process-filter "python"
glances --enable-process-extended   # then press 'e' on a process

That last one is the hidden gem. Highlight a process, press e, and Glances shows you its open files, its threads, its I/O counters and its CPU affinity, live. That is lsof plus /proc/PID/status without leaving the screen.

The keys worth learning

Glances is entirely keyboard-driven and the help screen (h) lists about sixty bindings, which is sixty too many. These are the eight that survive contact with real use:

/ deserves a mention of its own. By default Glances shows the process name only, which on a container host means twelve rows saying python3 and no way to tell them apart. Press / and you get the full command line, arguments included, and suddenly you can see which one is the backup script and which is the thing that has been at 100% for an hour.

a is the one people lose by accident. Press m to check memory once, forget, and the auto-sort is gone for the rest of the session — you are now looking at a static memory sort while the machine’s actual problem is disk. Press a and Glances resumes reading the room.

The other habit worth building is --process-filter, which takes a regex and is the fastest way to answer “what is this one service doing”:

1
2

glances --process-filter "postgres|redis"
glances --process-filter ".*python.*worker.*"

The filter narrows the process list while leaving every other section showing the whole machine, which is exactly the right behaviour and took me an embarrassingly long time to discover.

Client-server mode, which nobody uses

Glances can run as a daemon and be viewed remotely, and this is the feature I would put on the box if I were designing the packaging.

On the monitored host:

1

glances -s --bind 127.0.0.1 --port 61209 --password

On your workstation:

1
2

ssh -L 61209:127.0.0.1:61209 lab-01 -N &
glances -c 127.0.0.1 --port 61209

You now have the full Glances curses UI, running locally, showing the remote machine, at full refresh rate. The transport is XML-RPC over a plain socket, which is why I bind to localhost and tunnel over SSH rather than exposing 61209 anywhere. --password prompts once and caches a hash in ~/.config/glances; treat it as a speed bump rather than a security control.

There is also a browser mode, glances --browser, which auto-discovers other Glances servers via Zeroconf and gives you a list to pick from. It works, it is charming, and it depends on mDNS working reliably across your network, which mine does not.

The genuinely useful variant is the one-liner that needs nothing installed on the target at all:

1

ssh lab-01 -t 'docker run --rm -it --pid host --network host -e TERM nicolargo/glances:4.3.0.8-full'

Ugly, and it works on any host with Docker and no Glances.

The web UI and the API

glances -w serves the same dashboard as a web page on port 61208, and it is a faithful reproduction rather than a reimagining. It also, and this is the part worth knowing, exposes a REST API:

1
2
3
4
5
6
7
8

# Everything, as JSON
curl -s http://127.0.0.1:61208/api/4/all | jq 'keys'

# Just the filesystems
curl -s http://127.0.0.1:61208/api/4/fs | jq '.[] | {mnt_point, percent}'

# One value
curl -s http://127.0.0.1:61208/api/4/mem/percent

Which makes Glances a general-purpose “read a number off a host” service for scripts, with no code on your part. I have a small shell script that pulls fs from four machines and prints a sorted table, and it is thirty lines because Glances did all the work.

It exports, too. The list of backends is long and slightly absurd — InfluxDB, Graphite, MQTT, Kafka, CSV, RabbitMQ, Cassandra, and Prometheus:

1
2

glances --export prometheus --quiet
# now scraping http://0.0.0.0:9091/metrics works

I want to be clear that I do not recommend this. It works, and it means running a Python process per host to do a job that node-exporter does in 15 MB of Go with better metric naming and no Python at all. If you are building a Prometheus and Grafana stack, use the proper exporter. Glances’ export mode exists for people who already have Glances everywhere and want something quickly, and for that it is fine.

A note on what the numbers mean

Glances gets almost everything from psutil, which reads /proc and /sys, which means it inherits Linux’s accounting quirks wholesale. Two are worth knowing before you make a decision based on a Glances screen.

Memory “used” is a judgement call. Glances shows the actual used figure — total minus available — rather than total minus free, which is the number that terrifies people into buying RAM they do not need. Page cache is counted as available because the kernel will evict it on demand. If Glances says 60% used, you have 40% genuinely spare, and the cache is doing useful work with the rest. This is the correct number and it is worth trusting.

CPU steal is the one to watch on a VM. On anything running under a hypervisor — a Proxmox guest, a VPS — the steal figure in the CPU breakdown is time the vCPU was ready to run and the host did not schedule it. A consistently non-zero steal means your neighbours are the problem and nothing you do inside the guest will help. Glances puts it on screen by default. Most tools bury it, and I have watched people spend a day optimising an application that was simply being starved.

Both numbers are also why a screenshot of Glances is a poor bug report. The screen is a moment. If the question is “was this happening at 03:00”, the screen cannot answer, and you want something with a database behind it.

Troubleshooting

Glances itself is the top process. This is the classic complaint and it is real. Python plus curses plus a full psutil sweep every 2 seconds costs meaningfully more than top — on a Pi 4 I have seen 4–6% of a core, and on a machine with 600 processes it is worse. Fixes, in order: raise refresh to 5, disable plugins you never look at, and use --disable-process-extended if you left it on. On a machine where 5% matters, run Glances from your workstation in client mode and let the server side do less.

No temperature or fan readings. pip install glances[sensors] or the equivalent extra, then confirm sensors works on the host at all. In Docker you additionally need /sys visibility, which --network host does not grant.

No containers listed. The containers extra is missing, or the Docker socket is not readable by your user. Glances reads it directly rather than shelling out to docker.

The screen is a mess of escape codes. TERM is unset or wrong, usually in a container or a cron context. Export TERM=xterm-256color.

Blank sections over SSH from a narrow terminal. Glances drops plugins that will not fit the terminal width and does so silently, so a narrow window quietly loses the network section. Widen the window; there is no warning.

The web UI shows stale data behind a reverse proxy. The front-end polls; some proxy buffering configurations hold responses. Disable buffering for that location, and remember that glances -w has no authentication whatsoever — put it behind real auth or bind it to localhost. Exposing it publicly hands a stranger your process list.

The honest verdict

The case against Glances is that it is a Python program doing a C program’s job, and it costs a few percent of a core to tell you things htop tells you for free. If your only question is “which process is eating the CPU”, htop is faster, lighter, universally installed and has better process-tree rendering. I still use htop daily and I am not going to stop.

The case for is the breadth. Glances answers “what is wrong with this machine” in one screen where htop answers “which process is busy” in one screen, and those are different questions. Disk, network, filesystem, sensors, containers and the warning history are all things htop will never show you, and the auto-sort puts the answer in front of you before you have formed the query.

Where it fits with everything else: Glances is the torch, Beszel is the small permanent dial, Netdata is the wall of instruments and Prometheus is the archive. They do not compete. The mistake is expecting any of them to do another’s job — asking Glances what happened last Tuesday, or asking Grafana what is happening in this exact second on a box you just ssh’d into. When the answer needs history, you want the stack and probably logs alongside it.

Who should install it: anyone who ssh’s into machines and has ever run top, then df, then free, in sequence. That is the entire pitch and it is enough. Put it in your base image next to curl and tmux and stop thinking about it.

Who should skip it: anyone on hardware where a few percent of a core is a real budget, and anyone whose muscle memory for htop is already load-bearing at 3 a.m. Changing the tool you reach for in an emergency is a decision with a real cost, and “it shows more things” might not clear it.