htop and btop vs top: Watching a Machine Work

top has shipped with Unix systems for decades and shows you everything you need, arranged in a way almost nobody finds readable. htop shows the same information with colour, a scrollable list, a process tree, and the ability to actually do something about what you find. btop adds graphs.

Of all the old-versus-new pairs, this is the one where the modern tool wins most clearly — and where the classic is still the one you have to know.

The short verdict

What each one gives you

The row that matters most is “kill without typing a PID”. In top, dealing with a runaway process means reading a PID off the screen, typing k, retyping the PID correctly, then choosing a signal. In htop you arrow to the line, press F9, pick the signal. Under pressure, at 2am, that difference is not cosmetic — mistyping a PID kills the wrong thing.

Installing

# htop
sudo apt install htop        # Debian, Ubuntu
sudo dnf install htop        # Fedora, RHEL, Rocky, Alma
sudo pacman -S htop          # Arch

# btop
sudo apt install btop
sudo dnf install btop
sudo pacman -S btop

# htop
sudo apt install htop        # Debian, Ubuntu
sudo dnf install htop        # Fedora, RHEL, Rocky, Alma
sudo pacman -S htop          # Arch

# btop
sudo apt install btop
sudo dnf install btop
sudo pacman -S btop

On RHEL, Rocky and Alma, both usually need EPEL enabled first: sudo dnf install epel-release.

The htop keys worth knowing

Six keys turn htop from a prettier top into a real diagnostic tool.

H is the underrated one. By default htop lists every thread, so a JVM or a browser can produce sixty rows for one program and hide everything else. Pressing H collapses them to one line per process and the list becomes readable again.

F5 answers a question nothing else answers well. Tree view shows the parent-child structure, so when twenty PHP workers are eating the machine you can see they all descend from one php-fpm master — and that restarting that master is the fix, not killing twenty processes individually. Processes and memory covers why that structure exists.

Set your defaults once with F2 and they persist in ~/.config/htop/htoprc. Worth turning on: hiding threads by default, and adding the IO_RATE column so you can see which process is hammering the disk.

Reading the header

Both tools show the same summary at the top, and it is worth knowing what the colours in htop’s bars mean, because they encode information the numbers alone do not.

That memory bar is the fastest cure for the most common misreading in Linux. A bar that looks nearly full but is mostly yellow means the machine is caching, not struggling — and htop shows you that at a glance where free -h requires knowing which column to read.

Similarly, a lot of orange in the CPU bars means the processor is waiting on storage. If the machine feels slow and the CPU bars are orange rather than green, no amount of CPU tuning will help — the disk is the bottleneck.

The top keys worth knowing

You will end up on a machine with only top. These five make it survivable.

M and c are the two that matter. M because “what is eating the memory” is the most common question you arrive with, and c because “python3” tells you nothing while the full command line tells you exactly which script is misbehaving.

top also has a batch mode, which htop’s interactivity cannot replace — it is how you capture a snapshot into a file or a script:

# One snapshot, non-interactive
top -b -n 1 | head -20

# Log the top processes every 30 seconds
top -b -d 30 >> /var/log/top-snapshot.log

# Just one process, over time
top -b -p 1481 -d 5

# One snapshot, non-interactive
top -b -n 1 | head -20

# Log the top processes every 30 seconds
top -b -d 30 >> /var/log/top-snapshot.log

# Just one process, over time
top -b -p 1481 -d 5

That last pattern is genuinely useful for a problem that only happens at 4am: leave it logging, read it in the morning.

Where top is still the right answer

• Any machine you do not control. Customer servers, minimal containers, appliances, rescue environments. top is there; htop is not.
• A machine already in trouble. When memory is exhausted you cannot install a package, and top uses less of what little is left.
• Scripts and logging. top -b produces parseable output. htop is designed for a human looking at it.
• Over a slow or awkward connection, where htop’s full-screen redraws are more painful than top’s.

The same rule as the rest of this section applies, with one adjustment: learn top, install htop — and here the learning genuinely is a fallback skill rather than a daily one. You will use htop nearly every time. You will need top perhaps twice a year, on the worst two days.

Where btop fits

btop is genuinely beautiful: scrolling CPU graphs, per-process disk and network activity, mouse-driven everything. On a desktop or a machine you are watching deliberately it is a pleasure.

For diagnosis, be honest about what it adds. Historical graphs help you see whether a spike is new or constant, and the per-process network view is something neither of the others has. Everything else is presentation. It also uses noticeably more CPU than htop, which is a poor trade on a machine that is already struggling.

Worth knowing about the wider family, since they answer different questions:

sudo iotop -o is the one to remember from that list. When the load average is high and the CPU is idle, it names the process responsible in about two seconds — a question none of top, htop or btop answers directly.

Quick reference

Related reading

• Inspecting processes — ps, top and finding the right PID
• Processes and memory — what those numbers actually mean
• ncdu and dust vs du — the same idea, for disk space
• ripgrep vs grep — searching file contents
• Reading Linux logs — the other half of diagnosing a slow machine
• systemctl — restarting the service you just identified