How to Set Up a TUI System Monitor
Installing and configuring a full-screen terminal system monitor for real-time CPU, memory, and process information, entirely keyboard-driven.
A TUI system monitor gives you real-time CPU, memory, and process visibility directly in the terminal — genuinely useful on a remote server accessed over SSH where a graphical task manager isn’t an option at all.
Step 1: choose a TUI system monitor
htop — the most widely used, mature, highly configurable
btop — modern, visually rich, mouse-clickable within
terminals that support it
glances — cross-platform, with an optional web interface
htop is the safest default choice for broad compatibility and familiarity; btop offers a more visually polished experience on terminals with good Unicode and true-color support.
Step 2: install your chosen monitor
sudo apt install htop # Debian/Ubuntu
brew install htop # macOS
pkg install htop # FreeBSD
Step 3: launch it and understand the default layout
htop
The top section shows per-core CPU usage bars and overall memory/swap usage; the lower section lists individual processes, sorted by CPU usage by default.
Step 4: sort processes by a different metric
htop: press F6, then select a sort column
(CPU%, MEM%, TIME+, etc.)
Sorting by memory usage instead of CPU, for instance, is useful when specifically hunting for a process consuming unexpected amounts of RAM.
Step 5: filter to processes matching a specific name
htop: press F4 (or /), then type a search/filter term
Useful for focusing on a specific application’s processes in an otherwise busy process list, without needing to visually scan past everything else running.
Step 6: kill a process directly from the interface
htop: select a process, press F9, choose a signal
(SIGTERM is the default, safer choice; SIGKILL for
a process that won't respond to SIGTERM)
Being able to select and signal a specific process visually, confirming you have the right one before acting, is meaningfully safer than constructing a kill command against a PID you copied from separate output.
Step 7: view a process’s open files and network connections
htop: select a process, press l (lsof) or other
configured plugin keys, depending on your htop
build and configuration
Some htop builds and configurations expose additional per-process detail views directly, reducing how often you need to switch to separate command-line tools like lsof for basic investigation.
Step 8: customize the displayed metrics and layout
htop: press F2 (Setup) → Meters →
add/remove/rearrange CPU, memory, swap, and other
displayed meters
The setup screen lets you tailor exactly which system metrics are visible and how they’re arranged, rather than being stuck with htop’s default layout.
Step 9: save your configuration for future sessions
htop automatically persists Setup-screen changes to
~/.config/htop/htoprc
Once configured to your preference, htop remembers your layout and settings across future launches without needing to reconfigure each time.
Why a TUI monitor is often the right tool even when a GUI one is available
Beyond remote-server scenarios where no GUI exists at all, a TUI system monitor stays lightweight, works identically over SSH or locally, and integrates naturally into a terminal-centric workflow — running alongside your actual work in a dedicated tmux pane, rather than requiring a context switch to a separate graphical application entirely.
Where htop specifically came from, and why its name means what it does
htop is the work of Hisham Muhammad, with initial development running from 2004 through version 1.0’s release in November 2011 — eight years of iteration before that first stable milestone. The name itself is a direct play on “top,” the older, more limited Unix process viewer htop was built to improve on: the leading “h” stands for Hisham himself. Version 2.0 in February 2016 extended support beyond Linux to FreeBSD, macOS, and Solaris. Development activity slowed around 2019, prompting a community fork in 2020 led by contributors from Red Hat and Debian under the htop-dev organization — a transition Muhammad himself has publicly endorsed, meaning the htop you install today is maintained by that successor community rather than by its original single author.
Where btop fits relative to htop
btop (styled btop++) is the same author’s third iteration on this idea — following bashtop, then a Python rewrite called bpytop, then the current C++ version — chosen specifically because C++ let the project become significantly faster and more resource-efficient than its own earlier Python incarnation. Visually, btop leans further into true-color graphs and a more polished default layout than htop’s plainer table view, and it added GPU monitoring (Nvidia, AMD, and Intel integrated GPUs on Linux, plus Apple Silicon GPUs on macOS) as a dedicated development milestone — genuinely useful on a machine doing GPU-bound work like local model inference or rendering, where CPU and memory alone don’t tell the whole story. htop remains the safer default for minimal or unusual environments purely because of how long it’s been the de facto standard; btop is worth choosing deliberately when its richer visuals or GPU metrics specifically matter to what you’re monitoring.
Reading load average correctly alongside per-process detail
Both htop and btop display the system’s load average — three numbers representing the average count of processes wanting CPU time over the last 1, 5, and 15 minutes — directly alongside live per-process CPU percentages, but the two numbers answer different questions. Per-process CPU percentage tells you which process is consuming the CPU right now; load average tells you whether the system has been under sustained demand over recent minutes, including processes waiting on disk I/O on some systems’ calculation of it, not purely CPU-bound ones. A process list showing no single process at high CPU usage alongside a stubbornly high load average is a specific, recognizable pattern worth knowing — it usually points toward I/O contention or a large number of lighter processes collectively adding up, rather than one obvious runaway process a sort-by-CPU view alone would surface immediately.
Related:
Sources: