You are triaging a busy Linux server that has both top and htop installed. What does htop's interactive display give you that a flat, non-interactive process list does not, and what do its per-core CPU meters and their coloured segments actually show?

## What htop actually is htop is a full-screen, interactive process viewer built on ncurses. It has no privileged access and no special data source: like every other process viewer on Linux it reads `/proc` — `/proc/stat` for CPU time, `/proc/meminfo` for memory, and a handful of files under `/proc/<pid>/` for each task. The entire difference is the interface. That matters more than it sounds, because during triage the limiting factor is usually not what data exists but how fast you can navigate to the row that matters. ## The header: one meter per logical CPU By default htop draws one bar per logical CPU as the kernel counts them, so a machine with 8 hardware threads gets 8 bars. Each bar shows how that core's time was spent **during the last refresh interval** (roughly a second and a half by default), not since boot. That distinction is the source of a lot of confusion: the bars are a rate, and they move. The single most valuable reading skill is the *shape* of the meters rather than any one number: - One bar pinned near 100% while the rest sit near zero: a single-threaded workload. The machine is not out of CPU — one thread is out of CPU. Adding cores does nothing; adding worker processes, or making the hot path cheaper, does. - Every bar high: the host really is CPU-saturated, and the next question is which processes own the time. - Bars bouncing between cores: work that migrates, typical of many short-lived tasks. ## What the colours mean In htop 3's default colour scheme each bar is subdivided: - **green** — time spent in user space at normal priority; - **red** — kernel (system) time; - **blue** — low-priority, niced user time. A bar that is mostly red is a genuine finding, not a decoration: the workload is spending its time inside the kernel on that task's behalf — heavy syscall traffic, filesystem work, softirq handling for network load. That points you at a syscall tracer or a profiler next, not at a bigger instance type. A bar that is mostly green points at the application's own code. Enabling *Detailed CPU time* under F2 Setup splits each bar further, exposing IRQ, soft-IRQ, IO-wait, steal and guest time as separate segments. On a virtual machine a visible steal segment is worth noticing: the CPU you were promised is being spent elsewhere by the hypervisor, and no amount of application tuning will recover it. ## The process panel: tree view and the full command line F5 (or `t`) toggles the tree view, indenting children under their parents. This is the fastest way to answer "where did this come from?" — that forty identical worker rows all descend from one master process, or that the runaway was launched by a wrapper script from a scheduled job rather than by the service manager. htop also shows the **full command line** from `/proc/<pid>/cmdline` rather than a truncated program name, and the row scrolls horizontally. When a host runs dozens of processes with the same executable name, the arguments are usually the only thing that distinguishes them: which queue, which config file, which shard. The F2 setup screen controls presentation details here, such as whether the program path is shown and whether the basename is highlighted; the settings persist to `~/.config/htop/htoprc`. ## Finding a row: search versus filter Two keys do superficially similar things and are worth keeping straight: - `/` (F3) is **incremental search**: it moves the cursor to the next matching row and leaves the rest of the list intact, so you keep the surrounding context. - `\` (F4) is a **filter**: rows that do not match are hidden until you clear it. `u` narrows to one user, `H` toggles display of user threads, and `K` toggles kernel threads. F6 changes the sort column, and htop accepts mouse clicks on column headers and on the function-key bar. Command-line options preselect the same states, which is handy when you always want the same view: ``` htop -t -u www-data ``` ## Where the interactivity stops helping Because it is only an interface, htop adds no data the static tools lack, keeps no history, and produces no artefact you can attach to a ticket. It is an excellent way to *look*, and a poor way to *record*. Use it to orient yourself and to find the row that matters; move to a snapshot or a sampled stream the moment you need something to keep.