htop: a cross-platform interactive process viewer built on ncurses

What htop replaces, and who ends up using it

The problem htop addresses is the one `ps` leaves open. A plain `ps` invocation prints a snapshot and exits; reading it means knowing flags, and acting on a process means copying a PID into a second command. htop keeps the process list on screen, lets you scroll it vertically and horizontally, and lets you act on a selected process without ever typing its PID. The README describes it as "a cross-platform interactive process viewer" and notes that tasks such as killing and renicing can be done without entering PIDs.

The audience is anyone working at a terminal on a machine they administer or debug: a server over SSH, a laptop, a build box. The repository topics list Linux, macOS, BSD and console, so the target is not a single platform. System-wide information such as load average and swap usage sits alongside the per-process view, which means one screen answers both "is this machine busy" and "what is making it busy".

That combination is why htop shows up in so many distribution repositories. It is not a monitoring system. It holds no history, sends no alerts and stores no metrics; it shows the present moment and forgets it.

How htop is put together: C, ncurses and a panel model

htop is written in C and draws through ncurses, the library that handles terminal cursor movement and character output. The README states that running htop requires ncurses libraries, typically named libncurses(w), and that htop requires ncurses 6.0. Wide character support matters because the interface uses line-drawing characters; the README warns that on Debian and Ubuntu the wide variant is marked by an extra 'w' in the package name.

The source tree is organised around panels. Files such as AffinityPanel.c, AvailableColumnsPanel.c, AvailableMetersPanel.c, ColorsPanel.c and DisplayOptionsPanel.c each implement one configuration screen, which is why the README can say the displayed information is configurable through a graphical setup rather than through a config file you hand-edit. Meters are separate units too: CPUMeter.c, BatteryMeter.c, DateTimeMeter.c, DiskIOMeter.c, FileDescriptorMeter.c and GPUMeter.c each own one readout, and a meter can be placed in the header or hidden.

Platform-specific behaviour is compiled in rather than branched at runtime. Affinity.c and Affinity.h handle CPU affinity, with two mutually exclusive implementations: the README says `--enable-affinity` uses the sched_setaffinity and sched_getaffinity calls and conflicts with hwloc, while `--enable-hwloc` uses libhwloc instead. Several optional Linux features are loaded at runtime through dlopen rather than linked at build time, which the README documents for libsensors and for the libnl libraries behind delay accounting. That design keeps the mandatory runtime dependency list close to ncurses alone.

Installing htop on Linux and macOS, and a first real session

The shortest path is a distribution package. The README does not give a one-line install for end users; it points to the project homepage at htop.dev, and the packaging status badge links to Repology, which tracks which repositories carry which version. On Debian and Ubuntu the build dependencies are installed with:

sudo apt install libncursesw5-dev autotools-dev autoconf automake build-essential

Note the package name: libncursesw5-dev, with the 'w'. The README explicitly warns that the appropriate package is sometimes still called libncurses5 on Debian and Ubuntu, and that the 'w' marks wide character support. Fedora and RHEL use a different name:

sudo dnf install ncurses-devel automake autoconf gcc

On macOS the README gives `brew install ncurses automake autoconf gcc`. Once the toolchain is present, the build is the standard autotools sequence:

./autogen.sh && ./configure && make

`make install` then places the binary in /usr/local by default. The README notes that `./configure --prefix=/some/path` changes that location, which matters on systems where /usr/local is not on the path or is managed by something else.

A first session is keyboard-driven. Inside htop, `/` searches processes, `\` filters them, `t` toggles tree view, `.` changes the sort column, and `k` kills the selected process. The README points to `man htop` and to the in-app help menu, reached with `h` or `F1`, for the full key list. Filtering is the fastest way to turn a long list into the handful of processes you care about, and tree view is what shows you which shell spawned the process you are about to kill.

Build flags decide what htop can show, and the defaults are not generous

The configure script is where the interesting trade-offs live. Several features default to off or to a check, and a feature that is absent produces no error message in the interface; the meter or column simply is not there.

Backtraces are the clearest example. `--enable-backtrace` defaults to no, and its only documented value is unwind-ptrace, which uses libunwind-ptrace. Demangling is separate: `--enable-demangling` defaults to check and takes libiberty (GNU) or libdemangle (Solaris). So a stock build will not show you a stack trace for a stuck process unless whoever built it turned that on.

Temperature and CPU speed readouts depend on `--enable-sensors`, which defaults to check and requires libsensors at build time. The README adds a runtime detail worth knowing: libsensors is loaded through dlopen if available, so a binary can be built with sensor support and still show nothing on a machine without the library. Delay accounting works the same way with libnl-3 and libnl-genl-3. Linux capabilities support via `--enable-capabilities` defaults to check and needs libcap 2.21 or later.

Two flags change the shape of the program. `--enable-static` builds a static binary, but the README states that hwloc and delay accounting are not supported in that mode, which is a real loss if you wanted affinity or I/O accounting. `--enable-pcp` does not extend htop at all; it builds a separate pcp-htop utility against libpcp. And `--enable-debug` enables asserts and internal sanity checks, which the README says implies a performance penalty, so it is a development flag, not a production one.

Where htop is the wrong tool

htop is interactive by construction, and that is its main limitation. It has no documented mode that emits machine-readable output for a script, a log collector or a dashboard. If you need to record CPU usage over time, feed a graph, or trigger an alert, htop is not the program to reach for; it renders a terminal interface and expects a human at the other end.

Second, the build is not self-contained. The README lists a C99 compiler, autoconf, automake, autotools and ncurses as prerequisites, plus pkg-config as optional but recommended, and notes that some distributions supply pkg-config functionality through an alternative implementation called pkgconf. On a minimal container image or an embedded system without a build toolchain, compiling from source is more work than the tool justifies, and the distribution package is the only sensible route.

Third, the optional features are exactly the ones people ask about after installing. A user who expects temperature readings, backtraces or delay accounting and gets none has usually hit a build-time default rather than a bug. The README documents those defaults, but nothing in the interface tells you which flags the binary in front of you was built with.

Finally, htop is a viewer, not a supervisor. It can kill and renice, and the README says so, but it does not restart processes, enforce limits or persist configuration across machines in any documented way.

htop versus btop and the plain ps pipeline

The most common comparison is with btop, which appears in the related search terms alongside htop. The difference in approach is visible in the dependency list. htop is C plus ncurses, with a minimum runtime dependency set the README describes as kept as minimal as possible: ncurses libraries for terminal handling, and on Linux libdl when optional dependencies are present. That is a deliberate constraint, and it is why htop builds and runs on old distributions, minimal images and BSD systems without much fuss. btop is a different program with a different dependency profile, and anyone choosing between them should compare what each needs installed rather than what each looks like.

The other alternative is not a program but a habit: `ps` piped into `grep`, `sort` and `awk`. That approach is scriptable and produces text you can store, which htop cannot do. What it lacks is the interactive loop. With `ps` you read output, decide, then type a second command with a PID copied by hand; with htop you select a row and press `k`. For a one-off check in a script, `ps` wins. For the twentieth time you have to find which of two hundred processes is eating memory, the interactive view wins.

A third option worth naming is the Performance Co-Pilot path, since htop itself ships it. Building with `--enable-pcp` produces pcp-htop, a utility that talks to libpcp. That is the route toward recorded metrics, but it is a separate binary against a separate library, not a mode of the htop you already have.

Licence, maintenance and what an upgrade actually costs

htop is licensed GPL-2.0, and the README badge reads GPL v2+. That matters if you plan to link htop's code into another program or ship a modified binary: the copyleft terms travel with it. Reading the licence text in COPYING is the only way to be sure of your obligations; this is not legal advice, and the licence file is the authority.

The repository is not archived, and the last push was on 2026-09-20. Releases are frequent: 3.5.1 on 2026-04-28, 3.5.2 on 2026-07-18, and 3.5.3 on 2026-08-16. The ChangeLog file sits at the top level for anyone who wants to read what changed between them.

Upgrade cost depends on how you installed it. If htop came from your distribution, upgrades arrive with everything else and cost nothing beyond a restart of the program. If you built from source, an upgrade means repeating the autotools sequence, and the build flags are the part that bites: a rebuild that drops `--enable-sensors` or `--enable-capabilities` silently removes a feature you had before. Keeping the original configure line somewhere is the practical precaution. The README does not document a rollback procedure, so the fallback for a bad build is reinstalling the previous version or the distribution package.

Editorial conclusion

htop suits anyone who needs to sort, filter and kill processes on a Linux, macOS or BSD machine, and it is the right default when a distribution package is available. It is the wrong tool for scripted, non-interactive collection: it draws a terminal UI, so anything that needs machine-readable output should use a different program. Before adopting it, verify two things on your own system: that the ncurses package you install has wide character support, since the build depends on it, and which configure flags your distribution used, because sensors, capabilities and delay accounting are all optional at build time and their absence is silent at runtime.

Frequently asked questions

Official sources

1. htop-dev/htop on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases