htop system

The htop man page is 300 lines long. The interface explains itself. You need about five minutes and you’ll have a better system monitor than any GUI Task Manager ever built.

You already know about ps. It shows you a snapshot — processes at this exact moment. But sometimes you need to watch. CPU usage climbing. Memory slowly filling. A rogue process eating resources over time. You need something that updates continuously, like a dashboard.

On Windows, that’s Task Manager. You press Ctrl+Alt+Delete (a three-key combo that exists because IBM thought it was too unlikely to hit by accident), click “Task Manager,” wait for it to load, then stare at a list of processes that jumps around every time it refreshes. You can sort by CPU, but the numbers change faster than you can read them. You can sort by memory, but half the entries are named “Runtime Broker” and the other half are “Service Host.” You learn nothing.

htop is what Task Manager wants to be when it grows up. Color-coded CPU bars, memory usage, process trees, sorting, filtering, and killing processes — all in your terminal, all updating in real-time, all using approximately zero resources itself.

Unless you’re running Windows then wtf none of this applies to you. But hey, come to the dark side, go install WSL2 and you can follow along. We’ll wait. Impatiently.

If you’re lazy like me (all sysadmins are!) then click here for the htop cheat sheet.

htop vs top

top comes pre-installed on every Unix system. It works. It’s been working since 1984. But its interface is what you’d expect from 1984.

htop is top but with colors, mouse support, horizontal scrolling, process trees, and an interface designed by someone who actually uses a terminal. Install it:

sudo apt install htop

sudo dnf install htop

Both show real-time process information. If you’re on a server where you can’t install htop, everything on this page about navigation and sorting works in top too — just uglier.

Launch it

htop

  CPU[||||||||||||               32.5%]   Tasks: 142, 412 thr; 2 running
  Mem[||||||||||||||||||     1.84G/7.8G]   Load average: 0.52 0.44 0.38
  Swp[|                     12.0M/2.0G]   Uptime: 2 days, 05:14:32

  PID USER      PRI  NI  VIRT   RES   SHR S CPU%  MEM%   TIME+  Command
 1842 www-data   20   0  524M  115M  12.4M S  2.3  1.4  1:47.33 nginx: worker
 9823 owner      20   0 1842M  253M  22.1M R 45.2  3.1  5:33.01 node index.js
 2101 postgres   20   0  215M   68M  31.2M S  0.1  0.8  0:42.17 postgres

The top section shows CPU, memory, and swap as visual bars. Below that is the process list, sorted by CPU usage by default.

You can see immediately: node is eating 45% CPU and 253MB RAM. That’s your problem. You didn’t have to scroll through 200 processes to find it.

Navigate

The filter (F4) is especially useful — type “nginx” and only nginx processes are shown. Everything else disappears. No scrolling, no grep, just the processes you care about.

Sort by different columns

M for memory is the one you’ll use most after CPU. When something is eating RAM and you need to find it fast.

Kill a process

Select it with arrow keys, press F9, choose a signal:

• 15 (SIGTERM) — polite kill. “Please stop.” Default.
• 9 (SIGKILL) — forceful kill. “Stop now.” No negotiation.

Or use keyboard shortcuts:

• k then Enter — sends SIGTERM to the selected process
• Tag multiple processes with Space, then F9 to kill them all

This is the interactive equivalent of ps + kill. But you can see the process, select it, and kill it without typing a PID.

Tree view

Press F5 to toggle tree view:

├─ systemd
│  ├─ nginx: master process
│  │  ├─ nginx: worker process
│  │  ├─ nginx: worker process
│  │  └─ nginx: worker process
│  ├─ postgres
│  │  ├─ postgres: checkpointer
│  │  ├─ postgres: background writer
│  │  └─ postgres: walwriter
│  └─ sshd
│     └─ sshd: owner [priv]
│        └─ bash
│           └─ htop

Shows which processes spawned which. Useful for understanding relationships — nginx master spawned four workers, postgres has background processes, your SSH session is running htop.

Useful options

Show only your processes

htop -u owner

Filters to processes owned by a specific user. For shared servers where you only care about your own stuff.

Show specific PIDs

htop -p 1842,9823,2101

Monitor only these three processes. For when you’re watching a specific set of services.

Understanding the meters

CPU bars

Each bar is one CPU core. The colors mean:

If all bars are solid green, your application is using all available CPU. If bars show red, the kernel is busy (I/O, context switching). If you see cyan on a VM, your cloud provider is overcommitting.

Memory bar

Linux uses “available” RAM for disk caching. This is normal and good. The cache is freed when applications need memory. Don’t panic when the memory bar looks full — check the actual process usage.

Load average

The three numbers after “Load average” represent system load over the last 1, 5, and 15 minutes. As a rough guide: if the load average exceeds your number of CPU cores, the system is overloaded.

top (for when htop isn’t installed)

top

Same idea, older interface. The essential shortcuts:

top doesn’t have mouse support, tree view, or color coding. But it’s on every system. If you’re on a minimal server with nothing installed, top is always there.

The flags that actually matter

Inside htop:

“But Task Manager—”

Right.

“Task Manager shows me CPU and memory.” Task Manager shows you aggregate CPU as a single percentage and memory as a bar. htop shows you per-core CPU utilization with color-coded breakdowns of user, kernel, and steal time. It’s the difference between “your car is using fuel” and a full engine diagnostic.

“Activity Monitor on Mac has graphs.” Activity Monitor’s graphs are pretty. They show you history. They use 3% of your CPU to render themselves. htop uses approximately nothing and shows you what’s happening right now, which is what you need when you’re debugging a performance problem at 2 AM.

“I use Grafana for monitoring.” Grafana is for historical trends and dashboards. htop is for “what’s happening right now on this specific machine.” When Grafana alerts you that CPU is at 100%, you SSH in and run htop to find out why. They’re complementary.

“I just run ps aux | sort.” That gives you a snapshot. One moment in time. htop updates continuously. A process might spike to 100% CPU for three seconds and then drop back. ps would miss it. htop catches it because it’s watching.

htop cheat sheet

You made it. Or you skipped straight here. Either way, no judgment. Copy and paste these. Pin them. Tattoo them on your forearm. Whatever works.

The one command: htop — launch it, look at the bars, sort by CPU or memory, find the problem. Install it if you haven’t: sudo apt install htop.

Back to the top, you overachiever.