Skip to content
Shell & TerminalHow-To Published Updated 5 min readViews unavailable

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:

Comments