How to Interpret Linux Load Average Before Creating an Alert
Sources and verification
- Source dates
- Oldest source check: 12 September 2026.
- Technical verification
- Separate technical verification has not been recorded.
Publication approval and technical verification are recorded separately. Automated link checks establish reachability, not accuracy. A checked example verifies only its stated test cases, not the whole article or your production setup.
In short
Interpret Linux load average in the context of available CPU capacity, runnable work and uninterruptible tasks. Compare it with CPU utilization, pressure and service performance before deciding to page. A load of eight means something different on a two-CPU host than on a thirty-two-CPU host, and CPU normalization alone cannot distinguish useful work from I/O-related waiting or container limits.
Key takeaways
- Load average is not CPU utilization expressed as a percentage.
- CPU count is context, not a complete diagnosis or universal paging threshold.
- Use service impact and pressure measurements to decide whether action is urgent.
Read what the number represents
The Linux proc_loadavg manual (opens in a new tab) describes the first three values as load averages over one, five and fifteen minutes, reflecting runnable work and tasks in uninterruptible sleep. They are not percentages of CPU use.
A load average of eight can describe very different systems. On a small host it may indicate contention; on a larger host it may fit available CPU capacity. It can also rise while CPU utilization looks modest because the workload is waiting in a state counted by load.
Collect a small read-only baseline
These Linux commands inspect the local machine without changing its workload:
cat /proc/loadavg
getconf _NPROCESSORS_ONLN
cat /proc/pressure/cpu
cat /proc/pressure/io
cat /proc/pressure/memory
Pressure files depend on kernel support and configuration. Record an unavailable file as missing evidence, not as zero pressure. The kernel PSI documentation (opens in a new tab) explains how pressure measurements represent time affected by resource contention.
Collect CPU utilization, request latency, throughput and errors over the same window using the host and service monitoring already deployed. A one-off terminal sample may miss the behavior that caused the alert several minutes earlier.
Use CPU normalization carefully
Dividing load by online CPU count gives a rough context value for a host. For an illustrative load of eight, two CPUs produce a ratio of four, while thirty-two CPUs produce a ratio of one quarter. Neither ratio is a universal incident threshold.
Containers add another complication: visible host CPU count may differ from effective quotas or allowed CPUs. Check the workload's actual constraints and throttling before using host-wide normalization to explain its latency.
If exporting load and CPU metrics through Node exporter (opens in a new tab), verify the metric labels and target scope in your deployment. Avoid a fleet average that hides one constrained host carrying an important service.
Diagnose the pattern before changing a threshold
| Observation | Useful next check |
|---|---|
| High load and high CPU utilization | Runnable work, CPU pressure and recent workload changes |
| High load with I/O pressure | Storage latency, blocked work and dependency behavior |
| High load with memory pressure | Reclaim, allocation failures and workload memory demand |
| Low host load but slow container | Quotas, throttling and application dependencies |
| Load rises while service remains healthy | Capacity trend and expected batch activity |
These are investigation directions, not diagnoses. Several can occur simultaneously, and a service can fail for reasons that do not increase load at all.
Build an actionable alert policy
Start from a service symptom or a measured saturation condition with a useful response. If sustained load is a capacity warning that can wait, route it to an owned ticket. If it accompanies a failing customer journey, include it as context in the urgent alert rather than treating a fixed load value as the entire incident definition.
Replay a known busy but healthy period and a known degraded period against the candidate threshold. Include a batch workload and a container with CPU limits if those exist in the environment. Record whether the rule distinguishes them and what action a responder can take.
Review after changing host size, workload placement or quotas. A threshold tied to yesterday's capacity can keep firing even when the operational risk has changed, or stay quiet when a smaller workload allocation becomes the real bottleneck.
Did this help?
Your answer helps us improve this guide. We save only the page and your choice for 30 days.
No name, email, or incident details are requested.
Sources
Vendor facts change. Each source below shows the date this page last checked it.
- proc_loadavg manual — Linux man-pages. Checked 12 September 2026.
- Pressure Stall Information — Linux kernel. Checked 12 September 2026.
- Node exporter — Prometheus. Checked 12 September 2026.
Related
One practical idea, occasionally
The On-Call Brief: short field notes, templates, and operational lessons.
Follow the field guide
Email subscriptions are not open yet. Read new guides in your feed reader — no email address needed.
Subscribe with RSS