htop is an interactive, ncurses-based process viewer for Linux and other Unix-like systems that displays per-core CPU usage, memory, swap, load average and the full process list in a single terminal screen that refreshes continuously. In Linux monitoring, it is the tool administrators open first when a server feels slow, because it answers within seconds which processes consume resources and lets the operator sort, filter, renice or kill them without typing a process ID.
htop builds on the same kernel data as the classic top command, but adds scrolling, a process tree, mouse support and function-key actions. It is a separate package rather than part of procps-ng, so it is usually installed with the distribution package manager, for example apt install htop or dnf install htop.
How htop collects and displays process data
On Linux, htop reads its data from the /proc pseudo-filesystem, which the kernel generates on demand. System-wide counters come from files such as /proc/stat, /proc/meminfo and /proc/loadavg, while each process contributes /proc/PID/stat, /proc/PID/status and related files. htop samples these files at a fixed interval, computes the difference between two samples and turns raw tick counts into percentages.
The default refresh delay is 1.5 seconds, set in tenths of a second with htop -d 15. A shorter delay makes short CPU spikes visible but raises htop’s own overhead, because every refresh reads several files for every process and thread. On hosts with tens of thousands of threads, htop itself can consume a noticeable share of one core.
The screen has two parts. The header meters at the top summarize the whole system, and the process list below shows one row per process or thread. Both are fully configurable in the setup screen (F2), and the layout is saved to ~/.config/htop/htoprc when htop exits.
The following table explains the default header meters and how an experienced administrator reads them.
| Meter | What it shows | How to read it |
|---|---|---|
| CPU bars | Usage of each logical core | Green is user time, red is kernel time, blue is low-priority (niced) time, cyan is virtualization steal time |
| Mem | Physical memory use | Green is used memory; buffers and page cache are shown separately because the kernel can reclaim them |
| Swp | Swap space in use | Steadily growing swap with heavy paging signals memory pressure |
| Tasks | Processes, threads and running tasks | The running count is a snapshot of runnable tasks |
| Load average | 1-, 5- and 15-minute averages | Compare with the number of logical cores, not with 1.0 |
| Uptime | Time since the last boot | A short uptime can explain cold caches or a recent crash |
Reading the htop process columns
Each row of the process list is a set of columns whose meaning follows Linux kernel definitions, not intuition. Misreading them is the most common source of wrong conclusions, especially for memory columns and CPU percentages above 100%.
| Column | Meaning | Common pitfall |
|---|---|---|
| PRI / NI | Kernel priority and nice value (-20 to 19) | PRI 20 corresponds to nice 0 for normal tasks; RT marks real-time tasks |
| VIRT | Total virtual address space | Includes reserved but untouched memory, so large values are often harmless |
| RES | Resident set size in physical RAM | Counts shared pages in every process that maps them |
| SHR | Resident pages that can be shared | Shared libraries inflate RES without extra cost per process |
| S | Process state | D means uninterruptible sleep, usually waiting on storage or a network filesystem |
| CPU% | Share of one core over the last interval | A process saturating four cores shows about 400% |
| TIME+ | Accumulated CPU time | Measures total work done, not current activity |
The state column deserves particular attention. R means running or runnable, S means interruptible sleep, Z means a zombie whose parent has not collected its exit status, and T means stopped. Many processes in state D combined with a high load average but idle CPU bars point to an I/O bottleneck, not to a CPU shortage.
Additional columns can be enabled in the setup screen, including I/O read and write rates, the control group, the OOM score and per-process Pressure Stall Information. The I/O columns read /proc/PID/io, which normally requires root privileges for processes owned by other users.
Interactive controls and process actions
htop is designed for keyboard-driven triage: the function-key bar at the bottom of the screen lists the main actions, and single-letter shortcuts cover the rest. The table lists the controls used most often in practice.
| Key | Action | Practical note |
|---|---|---|
| F3 or / | Search for a process by name | Jumps to matches while keeping all rows visible |
| F4 or \ | Filter the list | Hides every row that does not match the text |
| F5 or t | Toggle tree view | Reveals parent-child relationships and runaway forks |
| F6, P, M, T | Sort by column, CPU, memory or time | I inverts the current sort order |
| F7 / F8 | Lower or raise the nice value | Only root can raise priority by lowering nice |
| F9 or k | Send a signal | Defaults to SIGTERM (15); SIGKILL (9) cannot be caught |
| Space, c, U | Tag a process, tag with children, untag all | Actions then apply to all tagged processes |
| s, l | Attach strace or list open files with lsof | Requires the tools to be installed and sufficient permissions |
The u key filters by user, H hides or shows user-space threads, and K hides kernel threads. The a key sets CPU affinity and i sets I/O priority, which makes htop a lightweight control panel as well as a viewer. Non-root users can act only on their own processes and can only lower their priority, a restriction enforced by the kernel rather than by htop.
htop compared with other Linux monitoring tools
htop is a real-time, human-oriented overview. It is not a recorder and it does not replace specialized tools, so experienced administrators use it to locate the problem area and then switch to a tool that measures that area precisely.
| Tool | Main purpose | When to prefer it over htop |
|---|---|---|
| top | Classic process viewer from procps-ng | Minimal systems and scripted snapshots with batch mode (top -b -n 1) |
| vmstat | System-wide memory, swap, CPU and run queue counters | Logging trends at a fixed interval in a compact form |
| iostat | Per-device throughput, latency and utilization | Confirming a storage bottleneck suspected from D-state processes |
| strace | System call tracing for one process | Finding out what a busy or stuck process is actually doing |
| lsof | Open files, sockets and their owners | Investigating file descriptor leaks or a locked file |
A key limitation follows from this role: htop has no batch or logging mode, so it cannot be used for unattended data collection. For history and alerting, metrics must be gathered by a monitoring agent, by sar from the sysstat package or by a time-series system.
Common misreadings and limitations
Most mistakes with htop are interpretation errors rather than tool errors. The table pairs typical observations with their real cause and the appropriate next step.
| Observation | Likely cause | Next step |
|---|---|---|
| Load high, CPU bars low | Tasks blocked in state D | Check storage latency with iostat |
| Mem bar almost full of cache | Normal page cache use | Check available memory, not free memory |
| Huge VIRT values | Reserved address space | Watch RES and swap activity instead |
| Process above 100% CPU | Several threads on several cores | Press H to inspect individual threads |
| Many zombie processes | Parent not reaping children | Fix or restart the parent process |
Inside containers, htop may show host-wide meters while the process list is limited to the container’s PID namespace, so CPU and memory limits set by cgroups are not visible in the header. Short-lived processes that start and exit between two refreshes never appear at all, which is why intermittent spikes require tracing or accounting tools.
A plain-language summary
htop is like a live dashboard for a Linux computer. It shows how busy each processor core is, how much memory is in use and which programs are responsible, updating every second or two.
Instead of guessing why a server is slow, an administrator opens htop, sorts the list by CPU or memory and sees the culprit at the top. From the same screen, a misbehaving program can be slowed down or stopped with a few key presses. The main lesson is that htop shows where to look, while other tools explain the detail.
An example from practice
An administrator receives a complaint that a web application on an 8-core Linux server responds slowly. htop shows a load average of 12.4, 11.8 and 9.6, which is well above the core count, yet the CPU bars show only about 20% usage. Sorting by state reveals two dozen PHP worker processes in state D.
The administrator concludes that the workers are waiting for storage rather than computing. Running iostat confirms that the database volume is at 100% utilization with read latency above 40 milliseconds, caused by a nightly backup job reading the same disk. After the backup is moved to off-peak hours and its I/O priority is lowered, the load average drops below 3 and response times return to normal. htop identified the symptom in under a minute; iostat confirmed the cause.