A production Linux host is badly overloaded and you are on a laggy SSH session. A colleague suggests you run htop and read the numbers out to the incident channel. Why is an interactive process viewer a poor instrument in that situation, and what would you reach for instead?

## The instrument has to match the job htop is genuinely good at one thing: letting a human orient quickly on a machine they are sitting in front of. Everything else people ask of it during an incident, it does badly — not because it is poorly written, but because a full-screen interactive terminal program is structurally the wrong shape for capture, for automation, and for a host that is already in trouble. ## No batch mode, so no artefact htop is TUI-only. There is no non-interactive one-shot output mode, nothing to redirect into a file, nothing to pipe into a filter, nothing to timestamp. Whatever you learn from the screen leaves the incident as a sentence you typed by hand into a chat window, and by the time anyone reads it the numbers have changed. An incident needs artefacts: a captured snapshot with a timestamp, attached to the ticket, that the next person can read without trusting your transcription. This is where a batch-capable snapshot tool wins outright — anything you can run once, redirect to a file, and attach. Take the snapshot first, before you start exploring; the state you most want is the state that existed when you arrived, and interactive poking is exactly what destroys your chance to record it. ## No history A live viewer starts at the moment you run it. The interesting question in almost every incident is what changed, and change is a comparison against a time you were not logged in. htop cannot scroll back and has nothing to diff against. For "was this happening at 03:10?" you need collected data — a historical collector on the host, or a metrics pipeline off it — and no amount of staring at a live screen substitutes. ## The observer is not free Each refresh, htop enumerates `/proc` and reads several files for every task on the system, then re-renders the whole screen. On a normal host this is negligible. On a host with tens of thousands of tasks, or one whose CPUs are already fully committed, it is measurable work — and it is competing for exactly the resource you are trying to free. It is not unusual for an observer tool to appear near the top of its own list on a saturated box. Optional per-process columns that require reading a task's memory-map details make each pass markedly more expensive again; leave them off unless you specifically need them. The default refresh interval is around a second and a half. `-d` sets it in tenths of a second, so raising it is the cheapest single mitigation if you do want to sit and watch: ``` htop --readonly -d 50 -u postgres ``` ## The laggy link makes it worse A full-screen repaint every interval over a slow or lossy SSH session is a bad trade in both directions: the terminal spends the link's capacity redrawing, and what you see is whatever managed to arrive, which may be seconds behind the machine. A single command that prints a page of text and exits crosses a bad link far better than a program that repaints forever. ## It is a live-fire interface F9 sends signals, and F7/F8 change scheduling priority. On a production host, in the dark, in a hurry, with a cursor whose position you did not verify, that is an unnecessary hazard. htop 3.x accepts `--readonly`, which disables the system- and process-changing features outright; it is a sensible default for anyone using htop as an observation tool rather than a control panel. ## What to run instead A workable order for an overloaded box: 1. **Capture a snapshot** you can attach — a single non-interactive process listing, redirected to a file with a timestamp. 2. **Start a sampled stream** in another window for a short timeline: the system-statistics tools that print one line per interval give you a sequence you can keep, which is exactly what the live screen cannot. 3. **Then, if you still want to explore**, open htop read-only with a longer delay, narrowed with `-u` or `-p`, and use it for what it is good at: finding the specific row that explains the numbers you already captured. ## The general rule Interactive viewers are for orientation; recorded output is for evidence; collected time series are for history. Reaching for the interactive tool first is a habit that costs you the artefact, and the artefact is the thing the post-incident review will actually ask for.