Guide context: Published 13 October 2026. The situation below is an illustrative troubleshooting scenario, not a report of an AdminHint client incident. Banner artwork is illustrative.
A browser stalls, the fan spins up, and opening a folder takes longer than usual. Restarting might clear the symptom, but it also erases the moment you could have inspected. Start by watching the machine while repeating one slow action.
btop gives you a convenient place to look. It does not diagnose every performance problem or tell you which process is safe to stop. Treat its numbers as clues that narrow the investigation.
Install from your distribution’s repository
Check whether it is already available:
command -v btop
btop --versionOn Ubuntu or Debian, if your enabled repositories provide the package:
sudo apt update
sudo apt install btopOn Fedora:
sudo dnf install btopIf the package is unavailable, check your distribution’s package documentation rather than adding an unknown repository or piping a download into a shell. The upstream btop project documents platform requirements, installation, resource panels, and process inspection. Package versions and available panels can differ.
Make the slow action repeatable
Run btop as your normal user. Note what the machine looks like at rest, then perform the action that feels slow: open the same document, load the same page, or start the same local build. Keep the test short and change one thing at a time.
A useful observation has three parts: what you did, how long the delay lasted, and which activity changed during that interval. “The system is slow” is difficult to act on. “Opening this project causes one process to hold a core busy until the window appears” gives the next person something specific to investigate.
Read the panels together
| What you notice | Next question | Avoid assuming |
|---|---|---|
| CPU activity follows the delay | Which process is doing the work, and is that work expected? | A brief spike means an app is broken |
| Memory pressure grows with your workload | Does reducing tabs or jobs improve responsiveness? | Every byte reported as used is unavailable |
| Disk activity rises while apps stall | Is a copy, update, or background job competing for storage? | The disk must be failing |
| Network traffic appears during a slow remote task | Is it a transfer, or is the app waiting for a remote service? | Low traffic proves the connection is healthy |
Think about the job the computer is supposed to be doing. A video conversion legitimately uses CPU. A backup legitimately reads disks. The more revealing question is whether the delay continues after that work finishes, or appears when there is no obvious reason for the activity.
Follow up with read-only checks
free -h
df -h
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 12These are Linux checks using common procps and GNU-style tools. Available memory is more useful than looking only at the free column. Disk capacity and disk activity are different measurements: a busy drive may have plenty of space, while an almost-full filesystem may be quiet.
The process listing is a snapshot with its own accounting, so its percentages need not match btop’s live interval exactly. Use it to record names and IDs, not to force two displays to agree. Redact usernames, file paths, and application arguments before sharing screenshots publicly.
Try the smallest reversible change
If one of your own applications is the obvious source, save your work and close it normally. Repeat the original action and compare. If an update or backup is responsible, let it finish or reschedule it through its normal controls.
Avoid sending a kill signal to a process merely because it ranks first. It could be maintaining a database, completing a write, or keeping a service available. A forceful stop can turn a performance question into lost data. On a production server, record the observation and follow the service’s documented procedure.
When btop is not enough
If the desktop pauses but the resource panels show little activity, broaden the investigation. Reproduce the issue with another app, check whether it affects local files or only remote ones, and inspect the application’s own logs. A monitor cannot explain a DNS wait, a graphics problem, or every short-lived event by itself.
For longer-term server trends, our Prometheus and Grafana guide covers a different monitoring approach. Topic inspiration: How-To Geek’s btop coverage. The workflow here is an original diagnostic scenario, not a measured benchmark.
