At 3:07 in the morning the phone buzzes on the nightstand. A message in the monitoring channel says one of the machines is at load 12.
You get up, open the laptop, SSH in, type uptime. Load average 12.4, on a five-core box. Then top, and the CPU column adds up to roughly 20%.
The unpleasant part is not that the machine is broken. It is that you have no idea where to look.
High load with low CPU usually means something is waiting on IO, or a pile of processes are wedged in uninterruptible sleep. You want to know which process is writing to disk, and the default top view has no IO column. You want to know whether this started ten minutes ago or thirty seconds ago, and top keeps no history. You want to know whether the other machines are doing the same thing, and top cannot see another machine at all.
Same night, three tools, three different answers. btop lays CPU, memory, disk, network and the process tree across a single screen, and you can click the row you care about. Glances lets you watch in the terminal, or watch the same measurements in a browser on your own laptop. Netdata may already have drawn the packet rate for every network card between 3:02 and 3:07, and sent an alert about it, while you were still asleep.
These three get shoved into the same comparison posts constantly. They are not on the same track. Choosing wrong costs more than an extra package: you end up in front of a window that cannot answer your question at the exact moment you need an answer.
They are not answering the same question
I use a crude test to tell them apart: imagine what is left on the machine after you close the terminal.
With btop, nothing is left. It is an observation tool, a dashboard that unfolds in front of your eyes, and when you quit there is no history, no daemon, no listening port.
Glances may still be alive after you close the terminal, provided you started the server with -s. It opens a web interface and a REST API on port 61208, and the same collection result can be drawn as a table in the terminal or read by a browser, a script, or another system entirely. It sits in the middle.
Netdata was never built around opening it for a quick look. You install it and forget it. Port 19999 stays open, it samples once a second, writes to disk, learns what normal behaviour looks like, and sends its own messages when something drifts.
So the honest way to compare them is to ask how much each one is willing to keep for you, and what it charges for keeping it.
| Dimension | btop | Glances | Netdata |
|---|---|---|---|
| Installation | one command from the system package manager, or unpack a static binary | pip, pipx, uvx, Docker, brew; web support is a separate extra | official one-line script, Docker, platform packages |
| Interface | full-screen terminal, mouse supported | terminal, browser, REST API | browser-first, port 19999 |
| History | none, only the curves scrolling in memory | not kept by default, can export to InfluxDB, Prometheus, ClickHouse and others | built-in time-series store, tiered, vendor says about 0.5 bytes per sample |
| Alerting | none | thresholds only recolour the interface, notifications need an external system | hundreds of built-in rules, can send email, Slack, Telegram, PagerDuty |
| License | Apache-2.0 | LGPL-3.0 | GPL-3.0 for the Agent, separate NCUL1 license for the Web UI |
| Sense of size | a static binary of a little over 900KB | a full set of Python dependencies | a resident daemon plus a database |
The only number in that table I would call precise is the 973KB of the Linux static package for btop v1.4.8. Everything else is qualitative, because the footprint of all three projects depends on your hardware, which collectors you enable, and how long you keep data. Any measured XX MB claim stops being true the moment you change environments.
btop: unfolding the current second
Say you are on a small four-core machine compiling a Rust project and the fan has started to complain. top shows cargo at 380%, but you want to know which child process is eating it, whether you are in the compile phase or the link phase, and whether memory is about to run out.
Open btop and the first thing you get is a four-way split. One bar per core, memory and swap in separate colours, disk read and write throughput, network up and down. Below that, the process list, sorted by CPU by default. Press f, type rustc, and the list immediately narrows to the compiler processes. Select a row and hit enter, and the detail panel appears on the right with the full command line. Press e for the tree view and you can see the chain of children hanging under cargo, each with its own state. Hold on a process and press t to send SIGTERM, or k to send SIGKILL, without leaving the interface to type kill. The list can be paused too, which matters when you are trying to read a screen that keeps getting pushed up by new processes.
Of the three, it feels most like a tool in the hand. Mouse support is complete, every button with a keyboard shortcut can also be clicked. Theme files are shared with bpytop and bashtop, so ready-made colour schemes from the internet drop straight in. GPU support arrived after 1.3, covering NVIDIA, AMD and Intel integrated graphics with utilisation, VRAM, power draw and clock speed. Version 1.4 added process following and the ability to pause the process list. The project describes itself as the C++ successor to bashtop and bpytop, and that is what it is: the same idea with the Python runtime layer removed.
Installation is the most decisive part of the package. The release page offers a musl static binary. Unpack it, run sudo make install, done. Building it yourself on Debian is a different matter. The README currently asks for at least GCC 14 or Clang 19, a requirement that will put off a good share of them, which is why the distribution package or brew install btop is what nearly everyone uses. The static build buys compatibility with old kernels. The README says anything from 2.6.39 onward will run it, which is useful on the old CentOS boxes still in service somewhere in your estate.
The price is equally clear. Close it and the screen is gone. It writes no database, fires no alerts, and remembers nothing about ten minutes ago. If you want to review the spike you just watched, your only option was to take a screenshot while it was still on screen.
There is one class of situation where nothing else substitutes for it. You are already on the machine, you need to know within thirty seconds who is consuming what, and then you need to act. At that moment, any tool that requires opening a browser and waiting for charts to load is dead weight.
It also cannot do several things at all. Ten machines at once is beyond it. So is disk latency from last Wednesday, or a rule for the on-call rota that says call me if IOPS on this box goes past 5000. Those belong to the other two.
Glances: the same data, seen somewhere else
Change the scenario. You have six machines: one in the cloud, one in a friend’s rack, two Raspberry Pis at home, two in a test environment. You do not want to SSH into each of them, and you do not want to stand up a full monitoring stack just to look at memory.
Glances solves this by separating collection from presentation. On each machine you run the server with -s, and it serves on port 61208, with the bind address set by -B. Then on your laptop you run the client against that machine’s address, and the terminal fills with an interface almost identical to the local one, fed by the remote REST API. Or you point a browser at http://machine:61208 and get a responsive web panel that is still readable on a phone. There is also a browser discovery flag that finds every machine on the local network running Glances, which saves time once the count climbs.
This is the essential difference from btop. btop’s interface is the whole product. Glances’ interface is one of its outputs. The same CPU plugin result can become a bar in a terminal, a ring in a browser, plain text lines piped to a script through the stdout mode, or rows written to InfluxDB, Elasticsearch, PostgreSQL with TimeScale, ClickHouse, CouchDB, Prometheus or Graphite through the export mode. It can also be imported as a Python library and called directly.
The 2026 releases added something I find more interesting than it first sounds. Since 4.5.1 there is a built-in MCP server, so starting the server with MCP enabled lets an AI assistant query CPU, memory, network interfaces and processes on that machine directly. Previously you had to explain what you meant by take a look at the memory, and hope the model guessed the right command. Now it can read the fields. The design is consistent with everything else in the project: the data is the product, the interface is negotiable.
Two smaller features that get overlooked show the same preference. The fetch mode prints a one-shot health card, the machine’s condition on a single screen, which is a good thing to put in a login script so you see the state the moment you connect. The quiet CSV export writes samples without opening any interface at all, which pairs well with cron and saves you from parsing top output in a shell pipeline.
Its weakness sits in exactly the same place. Because it tries to do everything, it does nothing deeply. Web support needs the glances[web] extra, everything needs glances[all], the dependency set is not small, and Python 3.10 or newer is required. There is no password by default. The README states plainly that the server is unprotected as shipped, and that you need to run the set-password step to generate a hash, then put that hash into the [outputs] section of the configuration. Left on a public address, those two facts are an incident waiting for a date.
One more thing is easy to miss. Glances’ thresholds exist mainly to colour the interface: past warning it turns yellow, past critical it turns red. Telling you about it is somebody else’s job. If you are asleep, it will not wake you.
Netdata: for the hours when you are not there
Third scenario. At nine in the morning, support says a batch of orders failed around eleven the night before. You open Netdata and drag the timeline back to 22:50.
This is the only one of the three that can answer a question about the past. The default interface is on port 19999, and it opens into a dense wall of charts, each with a point per second. CPU is split into user, system, iowait and softirq. Memory is broken into a dozen dimensions. Disk gives you both IOPS and latency. Network is divided by protocol, containers by cgroup. Scroll further and there are nginx request counts, Postgres connections, Redis hit rates. The README says more than 800 integrations.
Three behaviours do most of the separating work, and the first is that it learns. Every metric gets a model trained at the edge, continuously compared against recent behaviour, and deviations get marked as anomalies. You do not have to know in advance what a normal iowait looks like on this box, because it works that out for itself.
The second is that it calls for help. Hundreds of alert rules ship with it. Email works out of the box, and Slack, Telegram, PagerDuty, Discord and Teams are all available. The README puts it plainly: if the machine has an MTA configured, mail alerts work by default.
The third is that it keeps the data. The built-in store is tiered and, according to the README, uses roughly 0.5 bytes per sample, which is what allows a small machine to retain weeks of high-resolution data instead of only rolled-up averages.
Tiering is how that works. The default database engine keeps raw per-second data at the bottom, downsamples to per-minute above that, then per-hour above that, so older data gets coarser as it recedes. The benefit is that you do not have to choose between high resolution and long history. The cost is that the disk keeps growing, and you need to set a cap in the configuration. Skip that, and a small machine discovers its root partition is full about six months later.
The price of all this is that it is a real service. It stays resident, it holds memory, it writes to disk, it listens on a port, and it produces enough charts that the first visit is mildly disorienting. If all you want is to know whether one machine is sluggish right now, installing it is using a sledgehammer. It also expects you to learn a few concepts: the Agent runs on the node, the Parent aggregates and extends retention, the Cloud handles cross-node views and permissions. None of that is complicated, but none of it is obvious the moment the installer finishes either.
There is a common misunderstanding to clear up. Three different things sit under the Netdata brand. The Agent is open source, runs on your machine, and handles collection, storage and alerting. The Cloud is a commercial service with a free tier and paid enterprise features. The Web UI uses NCUL1, a license of their own, not the GPL. So the sentence “Netdata is open source” is true of the Agent and false of the product as a whole.
Licensing, easier to trip over than you would expect
Nobody reads this section until the day the tool has to go into a product or a shipped image, and then it stops the whole project.
btop is Apache-2.0, the most permissive of the three. You can modify it, distribute it closed, and bundle it into a commercial product, as long as you keep the copyright notice and state your changes.
Glances is LGPL-3.0, and the boundary runs along linking. If you change Glances itself, those changes have to be published. If your program pulls data from it over the REST API, that is inter-process communication, and it does not reach into your code. Using it as a data source carries little concern. Modifying it and redistributing the result as closed source does not work.
The Netdata Agent is GPL-3.0, one notch stricter than the LGPL. Running it in your own datacenter, you can change whatever you like and publish nothing. Distribute a modified Agent, and the derivative work has to be GPL. The UI sits under a separate license with more restrictions than the GPL.
The practical summary: internal company use is fine with all three. Put a modified version inside something you sell, and btop is the least trouble, Glances comes next, and Netdata should go past legal before it goes anywhere else.
What each one actually costs you
Numbers alone are misleading here, because what matters is what they buy.
btop’s overhead is roughly the overhead of a terminal program. A static binary at 973KB, no runtime, no database, everything released when you quit. It runs on low-spec hardware, old kernels, and some decidedly strange embedded environments. There is no background cost because there is no background.
Glances adds a Python layer. Collecting through psutil is not expensive in itself. The interpreter starting up, the dependencies loading, and the ASGI service you leave running once web support is enabled are what cost you. Its resource curve is high while you are using it and still present when you are not. An occasional look costs nothing worth counting. Running the server on twenty machines means doing the arithmetic on the total.
Netdata is the heaviest of the three, and that is a consequence of what it does rather than a sign of bad implementation. A resident process, a time-series database, a model per metric, hundreds of collectors loaded as needed. The README cites a 2023 University of Amsterdam study that named it the lowest-energy monitoring tool in Docker scenarios. A vendor citing third-party research is something you can discount as much as you like, but the point it illustrates holds: heavy does not automatically mean inefficient, and heavy can still be orderly.
My own rule is rough. If the machine has less than 1GB of memory, no Netdata. If all I want is to know who is eating CPU right now, no Netdata. If I need to answer what happened with that timeout spike at three yesterday afternoon, then I would rather give up something else and install it.
So which one do you type tonight
Back to three in the morning.
If the only question is now, btop is fastest. One command, one screen, two clicks to find the process, t or k to deal with it, done. It needs no prior deployment, no configuration, and no network access.
If you have more than one machine, or you want scripts to read the same numbers, Glances fits better. Start the server once, and from then on the terminal, the browser and the API are all available, and you can push the data into the Prometheus you already run.
If what you need is the ability to ask later, or you would rather not be woken at all, it has to be Netdata. It takes the night shift for you, and in exchange it takes up a bed of its own.
There is no conflict in running all three. Netdata for the long-term record, btop for detail when you are inside the box, Glances as the pipe that hands data to external systems. That combination is what a lot of people run. The failure mode that hurts is installing one of them and then discovering, deep in a night that needs a different kind of answer, that it cannot give one.
One thing to check before you install anything: ports 61208 and 19999 have no authentication by default. Do not expose them directly to the internet. Put them behind a reverse proxy with authentication, or bind them to the internal network only. A monitoring tool turning into the way in happens every year.
Last point, and it is a slightly deflating one. None of these three replaces the picture in your head. They can tell you the CPU is waiting on IO. Why it is waiting is still in the logs, in a slow query, or with the person upstream who changed a config an hour ago. What a tool can do is shrink the problem from an entire system down to one screen. The step after that is yours.
Related reading
- Beszel vs Netdata vs Uptime Kuma: Picking the Right Lightweight Server Monitor in 2026
- Pydantic AI vs LangGraph vs Agno: How to Choose a Python Agent Framework
- OpenCLI vs page-agent: Two Ways to Let an AI Agent Drive the Web (2026)
- invisible_dots vs Camoufox vs Patchright: Which Anti-Detect Browser Do You Actually Need?
- Conductor vs Temporal, Inngest and Restate: Choosing Durable Execution for AI Agents
Stay updated with our latest AI insights
