htop and top on Linux: understanding every metric displayed

You open htop and watch columns, numbers, and cryptic letters scroll by. You know something is happening, but you’re not quite sure what. This guide breaks down every element displayed by htop and top on Linux, leaving nothing in the dark.

Understanding htop and top metrics: where to start

The htop command reads its data directly from the /proc pseudo-filesystem. There’s no magic here: it’s the Linux kernel exposing its internal information as readable files. htop, top, ps, and other monitoring tools all do the same thing: walk through /proc/<pid>/ for each process.

Let’s start at the top of the interface, where the global system indicators are concentrated.

Uptime and load average: don’t mix them up

Uptime

Uptime tells you how long the system has been running. The uptime command reads from /proc/uptime. The first number is the total seconds since boot. The second is time spent idle, and it can exceed the uptime on multi-core machines because it adds up the idle time of each core.

Load average: the most misunderstood metric

Load average shows three values: the average load over the last 1 minute, 5 minutes, and 15 minutes. These values come from /proc/loadavg.

Here’s what many people miss: a load average of 1.0 on a two-core machine means 50% CPU utilization, not 100%. The number represents the average count of processes in a “running” state or waiting on disk or network I/O.

Another commonly missed point: the calculation is not a simple moving average. It’s an exponentially weighted moving average. The 1-minute value incorporates 63% of the last minute’s load and 37% of the history since boot. A high load average with a quiet CPU often points to processes blocked on I/O, not a CPU problem.

For accurate instantaneous CPU utilization, use mpstat (from the sysstat package) rather than relying on load averages.

Processes and their states

PID and process tree

Every process gets a unique numeric identifier: the PID. The init or systemd process always holds PID 1. It’s launched at boot and becomes the ancestor of all other processes.

When you launch a program from bash, here’s what happens:

bash creates a child process via fork
the child loads the program into memory via exec
bash waits for the child to finish

In htop, press F5 to display the process tree. You’ll clearly see the parent/child relationships.

Process states

The S column in htop shows the current state of a process. Here’s what each letter means:

R: running, the process is using the CPU or waiting its turn in the queue
S: interruptible sleep, the process is waiting for an event and can receive signals
D: uninterruptible sleep, typically waiting on disk or network I/O, cannot be interrupted
Z: zombie, the process has finished but hasn’t been cleaned up by its parent yet
T: stopped by a job control signal
t: stopped by a debugger

State D is the one to watch out for: a process stuck in D for a long time usually indicates an I/O or device problem.

Threads and kernel threads

In htop, press Shift+H to show user threads. Shift+K shows kernel threads. The interface displays something like Tasks: 23, 10 thr when threads are visible.

Users and process ownership

Every process belongs to a user, identified by a numeric UID. htop reads this UID from /proc/<pid>/status and resolves it to a name via /etc/passwd.

An important security detail: some executables carry the setuid bit (the s in permissions). This means the process runs with the rights of the file’s owner, not the user who launched it. That’s the case for /usr/bin/passwd, which needs to write to /etc/shadow as root.

Find setuid binaries with: find /bin -user root -perm -u+s

Signals: interacting with processes

From htop, you can send a signal to a process via F9. A signal is simply an integer. The most useful ones:

SIGTERM (15): asks the process to terminate gracefully
SIGKILL (9): kills the process with no way to intercept it
SIGINT (2): equivalent to Ctrl+C in the terminal
SIGSTOP / SIGCONT: pauses or resumes a process

Unlike SIGTERM, SIGKILL cannot be caught or ignored by the process. It’s the last-resort hammer.

Key takeaways

Load average measures the average number of active or I/O-blocked processes, not CPU utilization directly. Divide by the number of cores to interpret it correctly.
All data displayed by htop comes from /proc: uptime, loadavg, process state, user, command.
State D (uninterruptible sleep) is a warning sign for I/O problems.
The setuid bit on an executable changes the effective owner of the launched process: a critical point to audit regularly.
mpstat gives an instantaneous view of CPU utilization, more accurate than load averages for diagnosing real CPU load.

If you want to dig deeper into system performance analysis or talk about tools like btop++ (the modern successor to htop), feel free to reach out or follow the blog for upcoming articles.

Sources

htop explained, Peteris Rocks: the original detailed reference for every htop metric
Official htop repository, GitHub htop-dev: project source code and documentation
htop man page: official project website
Linux kernel, kernel/sched/loadavg.c: load average calculation implementation in the kernel