How to Check the CPU Usage in Linux: A Guide
The page is frozen, the API is timing out, and the pager just lit up at 2 a.m. On a Linux host, the first instinct is to open a terminal and check CPU usage, but the number in front of you only helps if you know what it means. A busy box can be CPU-bound, stuck on disk, or waiting on a single hot thread while the rest of the machine sits idle.
Table of Contents
- Why CPU Usage Is More Than a Number
- Quick One-Liners With top and ps
- Going Deeper With htop, mpstat, and pidstat
- Reading /proc/stat and Historical Trends With sar
- Per-Core, Per-Thread, and Hotspot Hunting
- Container-Aware and Remote CPU Checks
- From One-Off Checks to Continuous Monitoring
Why CPU Usage Is More Than a Number
A production API returning 504s at 2 a.m. is exactly the kind of incident that tempts people to stare at one terminal line and declare victory. That usually goes wrong. CPU usage, load average, and iowait tell different parts of the story, and mixing them up leads to bad conclusions.
Start with the time window and denominator. CPU utilization describes how CPU time was used over an interval; it is not an instantaneous sensor reading. Linux load averages cover 1, 5, and 15 minutes and include runnable tasks plus tasks in uninterruptible sleep, so load is not CPU percent. The procps uptime manual explains that distinction. Check per-core activity and workload limits before comparing load with the host's logical CPU count.
Practical rule: don't read a CPU number without the surrounding context. A single snapshot rarely explains whether the machine is actually saturated or just momentarily active.
That's why experienced operators treat how to check the CPU usage in Linux as a layered question, not a single command. The first question is whether the box is doing work. The second is whether that work is on the CPU, blocked on I/O, or concentrated in one process or thread.
The phrase “high CPU” is also used too loosely. A process can burn CPU while the system still has headroom on other cores, and a system can feel slow when CPU usage isn't extreme because tasks are waiting elsewhere. Good diagnosis starts by separating activity, contention, and latency.
Load average gets misunderstood easily in production, and this short guide explains the trap well.
Quick One-Liners With top and ps
Use top for an interactive first look. Task %CPU normally describes CPU time since the preceding refresh. In the usual Irix mode, 100% means one logical CPU and a multithreaded process can exceed 100%; Solaris mode divides by the total CPU count. Read the mode and a few refreshes before comparing task percentages with the host summary. This view does not reconstruct a spike that has already ended.
Use top for live triage
top answers the immediate question, “what is hot right now?” Sort by CPU with P, then toggle the per-core display with 1 if the host has multiple CPUs. On a multicore box, the overall summary can hide that one core is doing most of the work while the rest sit mostly idle.
A clean habit is to keep top open while watching a deployment or restart. That gives a live read on whether CPU pressure appears during startup, cache warmup, or request bursts. It also reveals when a process is using multiple threads across cores, which is where %CPU can exceed what newcomers expect.
Use ps when you need a one-shot snapshot
For SSH sessions, scripts, or incident notes, ps is the simpler tool. The most practical one-liner is:
ps -eo pid,user,pcpu,args --sort=-pcpu | head -n 11
This lists a header and up to ten processes sorted by ps CPU percentage. That percentage is CPU time divided by elapsed process lifetime, so a recent burst in an old process can look small. It is useful for a compact ranking; use pidstat -u 1 5 when you need recent one-second intervals.
topshows activity over refresh intervals.psreports a lifetime-average CPU percentage for each process.
The trade-off is straightforward. Use top when the incident is active and the machine is changing under your feet. Use ps when you want something scriptable, repeatable, or easy to paste into a ticket. For a broader troubleshooting flow, the companion note on why your server feels slow when top shows 50% idle is a useful reminder that “idle” doesn't always mean “fine.”
Going Deeper With htop, mpstat, and pidstat
top is enough to start. It isn't enough to answer every question. Once the first spike is identified, the next step is to move from broad visibility to cleaner per-core and per-process detail, and that's where htop, mpstat, and pidstat earn their keep.
htop for a clearer interactive view
htop is the friendlier version of top for operators who live in terminals all day. It shows per-core statistics by default, which saves a keystroke when the host has many CPUs, and its layout makes a noisy system easier to read at a glance. The visual overhead is lower than raw top, especially when the machine is busy and the screen is changing quickly.
That said, htop is still an interactive tool. It's excellent for live diagnosis, less useful for automation, and not a replacement for historical data. For teams that need a quick visual pass during an outage, it's usually the first upgrade from top.
mpstat and pidstat for cleaner evidence
mpstat -P ALL 1 5, from sysstat, prints five one-second reports for all logical CPUs. Use it to separate one hot core from balanced host load. pidstat -u 1 5 samples process CPU over the same kind of interval. The interval matters: omitting it from either command reports statistics since boot rather than a live series.
The official mpstat manual and pidstat manual document the interval and count arguments. Keep these explicit in incident notes so the next responder knows whether a result covers recent seconds or a longer average.
A few decision points matter in practice:
- Choose htop when you want an operator-friendly live console.
- Choose mpstat -P ALL 1 5 when one core may be hotter than the rest.
- Choose pidstat -u 1 5 when a specific service is suspected.
- Choose vmstat when you need a quick system-wide view of runnable versus blocked work.
This monitoring guide from Fivenines covers the same toolset in a practical Linux context.
The key trade-off is fidelity versus speed. htop is easy on the eyes. mpstat and pidstat are easier to defend in a postmortem.
Reading /proc/stat and Historical Trends With sar
Host CPU time is exposed in /proc/stat, in USER_HZ units. Recent host utilization is calculated from counter changes over a known interval. Process tools also use per-process accounting, such as /proc/PID/stat; they are not all reading only the host counters. The kernel proc documentation describes these interfaces and the limitations of iowait accounting.
Why one read is not enough
Read the measurement window before comparing percentages. A recent interval, an average since boot, and a process lifetime average answer different questions. For recent CPU activity, use explicit intervals and compare several samples instead of mixing these time bases.
The other trap is normalization. On multiprocessor systems, raw idle and busy values have to be interpreted per CPU or across cores carefully, or utilization gets overstated. Load average is also not CPU usage, so it should never be treated as a substitute for the /proc/stat counters.
A practical reading model is simple:
- Read
/proc/stat. - Wait.
- Read it again and compute the delta.
A CPU percentage needs a known time window and denominator to be useful.
sar for historical analysis
That same delta logic is what sar turns into history. Oracle's sysstat documentation describes enabling collection timers so the system keeps performance snapshots over time, and it shows sar -q for load averages and sar -u -P ALL for per-CPU statistics, which are the right tools when the incident is already over and the question is “what happened during the deploy?” Oracle sysstat documentation Collection must have been running before the incident; these commands cannot recover CPU samples that were never stored. For setup and retention checks, see the Linux CPU history guide.
Logged data changes the workflow. Live tools answer the present moment. sar answers the previous hour, the overnight incident, or the exact window where a rollout started misbehaving. That makes it possible to compare CPU behavior before and after a change instead of relying on memory and guesswork.
Per-Core, Per-Thread, and Hotspot Hunting
On modern hosts, a single CPU percentage is often too blunt to be useful. The machine might be fine overall while one core is pinned, one thread is spinning, or one function is chewing through cycles in a tight loop. That's why good CPU debugging moves from system summary to per-core, then to per-thread, and finally to function-level profiling if needed.
Read the machine the way it actually runs
A multicore box can make a process look confusing at first glance because %CPU is not capped at 100% in the way many people expect. A multi-threaded service can use multiple cores at once, so process-level usage can exceed 100% while the system still has spare capacity elsewhere. That isn't a bug, it's a sign that the process is parallelizing work.
top -H expands the view to threads. For repeatable interval output, use pidstat -u -t 1 5 to request CPU statistics with thread detail over five one-second intervals. Availability of other users' process details depends on system permissions.
Use pressure signals when utilization lies
Modern kernels also expose /proc/pressure/cpu, which is more useful than raw utilization when the pain is latency. That signal tells operators that tasks were runnable but could not get CPU time promptly, which lines up better with user complaints than a plain utilization number does. The reason matters, because a busy but healthy scheduler is a different problem from a queue of waiting work.
The kernel pressure-stall documentation describes the some CPU signal: the share of time at least some tasks are waiting for CPU. It complements per-core and thread samples; it is not another CPU-utilization percentage.
When the host is saturated and the responsible code path still isn't obvious, perf is the next escalation. That's the point where the question stops being “which process is hot?” and becomes “which function is consuming the cycles?”
Container-Aware and Remote CPU Checks
Containers change the meaning of a CPU percentage. A container can look fully used relative to its own quota while the host still has plenty of headroom, so host-level and container-level numbers have to be read in different contexts. That distinction is easy to miss when teams move the same debugging habits from bare metal to Kubernetes.
Host CPU is not the same as cgroup CPU
On Linux, docker stats expresses CPU usage relative to one logical CPU: roughly 100% means one CPU-equivalent, and a container using several CPUs can exceed 100%. It is not automatically a percentage of the configured quota. kubectl top pod reports CPU in cores or millicores, such as 500m for half a CPU, and requires a working Metrics API. Check the Kubernetes metrics documentation for its measurement window.
For a quota-relative percentage, divide measured CPU-equivalents by the configured CPU limit explicitly. For example, a workload using one CPU-equivalent with a two-CPU limit uses 50% of that limit, even though Linux docker stats can show about 100%. On cgroup v2, inspect the workload's cpu.max and interval changes in cpu.stat; include parent limits and placement constraints in the diagnosis.
Remote checks should stay simple
For bare-metal fleets and VMs, SSH still does the job. The safest pattern is to run the same known-good commands remotely, capture the output, and compare hosts side by side. For larger fleets, tools like pssh or Ansible let operators fan out the same top, ps, mpstat, or pidstat check without rebuilding the workflow every time.
Record the scope, denominator, and interval in incident notes so another operator can compare the host, VM, and container readings correctly. For a past incident, inspect data that was actually collected at the time; the sar manual explains how to read stored system activity files.
From One-Off Checks to Continuous Monitoring
Terminal commands are excellent for active incidents, but they only answer the question when someone is already there to ask it. Production systems need continuous CPU visibility, retention, and alerting, because the interesting spike often happens before the operator logs in. That's where agent-based monitoring beats ad hoc polling.
Why push beats ad hoc checks
A push-based Linux agent sends telemetry over HTTPS, which avoids inbound ports and remote command paths. That matters for security, but it also matters operationally when hosts sit behind NAT, live in segmented networks, or belong to customers who don't want management access opened broadly. Continuous collection also preserves the CPU trail that a one-off top reading can't provide.
Fivenines is one option in that category, it collects Linux server metrics, including CPU, and presents them alongside container, Proxmox, and other infrastructure data in one dashboard. It also routes alerts to email, Telegram, and Discord, with Slack, Microsoft Teams, Pushover, PagerDuty, and webhooks available depending on the plan, which gives ops teams a cleaner path from signal to action. For a broader tool comparison, the article on Linux server monitoring tools is a practical companion read.
What to look for in a platform
A good monitoring stack should do more than graph a CPU line. It should keep history, alert on sustained pressure, and let operators correlate CPU with memory, disk, and network behavior. It should also fit the way the team already works, whether that means dashboards, automation, or infrastructure managed as code.
A strong evaluation checklist is short. The platform should collect host and container telemetry, keep enough history for incident review, support alert routing your team already uses, and make it easy to answer the same questions that top, mpstat, and sar answer manually. If it can't do that, it's replacing one blind spot with another.
If CPU incidents keep catching the team after they've already started hurting users, Fivenines can help keep the signal in front of the incident. It collects Linux CPU telemetry with push-based agents, keeps the history needed for real diagnosis, and ties that data to alerts and dashboards your team can use. Visit Fivenines to see how it fits into a production monitoring workflow.
When a quick check needs to become a repeatable monitoring routine, explore Fivenines Linux server monitoring.
