Linux Load Average Explained: What the Numbers Mean

Updated on Sep 26, 2026

9 min read

Linux load average is a familiar line in uptime and top, but it is easy to mistake for a CPU-use percentage. For developers and system administrators, the values are more useful as a signal of how much work is competing for the system over time. This guide explains what Linux counts, how CPU capacity changes the interpretation, and how to investigate a high reading without guessing.

What Is Linux Load Average?

Load average is a set of three smoothed measurements of active work on a Linux system. The values represent averages over roughly the last 1, 5, and 15 minutes. On Linux, active work includes tasks that are running or ready to run, as well as tasks in an uninterruptible sleep state. The Linux kernel documentation for /proc describes the load-average and task information exposed through this interface.

The figures are counts of work, not percentages. A one-minute load average of 2.00 does not mean the CPU is 2% or 200% utilized. The system’s number of logical CPUs matters: two continuously runnable tasks on a two-CPU system can occupy both CPUs, while two runnable tasks on an eight-CPU system may leave capacity available. Even that comparison is only a first approximation, because Linux also counts uninterruptible tasks that are not using a CPU.

Linux exposes the raw values in /proc/loadavg. The Linux proc_loadavg manual page documents all five fields. The Linux uptime manual page explains why its displayed load averages include runnable and uninterruptible processes. This article focuses on Linux: the Linux Kernel Archives link to the upstream project and its maintained kernel documentation. Other operating systems may calculate or expose similarly named metrics differently.

Why Load Average Exists

A CPU can execute only a limited amount of work at once. When more tasks are ready than there are available CPUs, some wait in a run queue. A run-queue count helps describe contention, but a single instantaneous sample can change rapidly as tasks start, finish, or block.

Load average smooths that activity across three time horizons. The one-minute value responds more quickly to a new burst; the five- and fifteen-minute values provide a slower view of whether the pressure is sustained or subsiding. This makes the values useful in a login banner or monitoring overview, where an operator needs context rather than a snapshot that might disappear before it is read.

There is an important Linux-specific detail: the metric also includes tasks in uninterruptible sleep, often waiting for I/O to complete. As a result, it can indicate that work is stalled even when CPUs are not busy. That makes load average useful as a starting signal, but it cannot identify the cause on its own. Pair it with CPU, memory, and storage measurements.

How Linux Load Average Works

The Linux kernel tracks active tasks and updates exponentially smoothed averages. Recent activity affects the one-minute value more strongly than the fifteen-minute value, but none of the numbers is a precise count of tasks at this instant. They are weighted histories: after a brief spike, the values decline gradually rather than immediately returning to baseline.

A task contributes to Linux load while it is either:

Runnable: executing on a CPU or eligible to run but waiting for CPU time.
In uninterruptible sleep: blocked in a kernel wait that cannot be interrupted in the usual way, commonly while waiting for I/O.

This is why load average is not interchangeable with CPU utilization. A CPU-bound workload can raise both CPU utilization and load. Storage stalls can raise load while CPU utilization remains modest. Conversely, a high CPU utilization reading with little queued work may simply mean the available CPUs are doing useful work efficiently.

The /proc/loadavg file contains three averages followed by a task count and a PID. For example, an illustrative line might look like this:

0.42 0.31 0.29 1/735 24120

The first three fields are the one-, five-, and fifteen-minute averages. The fourth is the number of currently runnable tasks divided by the total number of threads. The fifth is the most recently created process ID. The kernel proc documentation and the proc_loadavg manual page describe these fields; the last two are a momentary snapshot, not more averages.

Linux’s /proc/loadavg is a kernel interface, not a portable operating-system standard. The POSIX definitions cover general process and scheduling terminology, but do not specify this Linux file or its load-average calculation. Scripts that need to run on multiple operating systems should not assume an identically defined metric.

Key Concepts for Interpreting the Values

Signal	What it tells you	What it does not tell you
1-minute average	Recent direction and short bursts	Exact current CPU use
5-minute average	Whether recent pressure is persisting	Which process caused the pressure
15-minute average	Longer-running system trend	Whether the system is healthy by itself
Logical CPU count	Rough execution capacity for comparison	A guaranteed amount of capacity for every process or container
Runnable task count	Current demand for CPU scheduling	The amount of time blocked tasks have been waiting

For a rough CPU-contention check, compare the load average with the number of logical CPUs available to the workload. If a four-logical-CPU machine has a sustained load around 4, its runnable work may be keeping those CPUs occupied. A sustained load well above 4 can indicate a queue of runnable tasks. These are clues, not thresholds: some of the load may be I/O-bound, and short-lived spikes may be normal.

Logical CPUs include hardware threads, which are not equivalent to independent physical cores for every workload. In virtual machines, a guest’s reported CPU count may not reflect host contention. In containers, do not assume a host-level load average reflects the CPU quota available to that container; check its CPU limits and throttling counters as well as the CPUs it can run on. Compare like with like and use application latency or throughput to determine whether the workload is actually missing its goals.

Real-World Uses

Load average is useful for spotting changes and deciding where to look next. A steady increase in all three values can point to growing demand or a persistent bottleneck. A one-minute value that rises sharply while the longer values remain low may reflect a short batch job or traffic burst. If the one-minute value falls below the fifteen-minute value, recent pressure may be easing, though the system could still be recovering.

The metric is especially helpful when paired with other evidence:

High load and busy CPUs suggest runnable work is competing for compute capacity.
High load, low CPU use, and many tasks in D state suggest blocked work; check storage latency and kernel wait channels.
High load with memory pressure may accompany reclaim or swap activity; inspect memory statistics rather than attributing the problem to CPU alone.
High load inside a container can coexist with modest host-wide utilization if the container is hitting its own CPU quota.

These are diagnostic directions, not proof. Confirm them with repeated measurements and the service’s own response times.

Practical Guide: Read and Diagnose Load

On many distributions, uptime, top, ps, and vmstat are already installed. If they are missing, install the system process tools with procps on Debian or Ubuntu, or procps-ng on Fedora-family distributions. iostat and pidstat are provided by sysstat.

Start with the summary and the raw Linux values:

uptime
cat /proc/loadavg
nproc
top

nproc reports processing units available to the current process on GNU systems, which can be more useful than a host-wide CPU count in a constrained environment. It does not turn the load average into a percentage or account for every form of CPU quota. Check container or service limits separately.

Next, sample runnable and blocked tasks. In vmstat, the r column is runnable work and b is blocked work; the first output line is a summary since boot, so use later lines to inspect current behavior.

vmstat 1 5
ps -eo pid,stat,wchan:24,comm | awk '$2 ~ /^D/ { print }'

If ps lists tasks in D state, inspect what they are waiting on before changing CPU scheduling. For storage-related symptoms, install sysstat if needed and sample device activity:

iostat -xz 1 5
pidstat -d 1 5

For a high load with busy CPUs, use top or ps to identify processes consuming CPU. For high load with low CPU use, inspect blocked tasks, device latency, and application dependencies. In a container or systemd service, also check the configured CPU quota and throttling metrics: raising process priority will not override a cgroup limit.

Take several samples under normal and degraded conditions, and compare them with the same workload’s latency and throughput. This separates an unusual number from an actual service problem. Only after identifying a bottleneck should you consider a configuration change; broad tuning based on a single load value can shift the bottleneck or make performance worse. See the Linux performance tuning guide for a broader measurement workflow.

Common Misconceptions

“Load average is CPU utilization.” It is not. Linux counts runnable and uninterruptible tasks, so the values can be high while CPUs are waiting on blocked work. Use CPU utilization and I/O measurements to learn what the tasks are doing.

“A load average above 1 is always bad.” The value has no useful capacity context without CPU availability, workload behavior, and service objectives. A load of 2 may be busy on a one-CPU system and unremarkable on a machine with many CPUs.

“The fifteen-minute number is the exact average for the last fifteen minutes.” It is an exponentially smoothed value, not a simple arithmetic mean over a fixed window. It weights older activity less, and it reacts more slowly than the one-minute value.

“A high load proves the CPU needs tuning.” High load can reflect blocked I/O, CPU quota throttling, or other waits. Find the source of the pressure first. For more on runnable tasks and scheduling behavior, see OS resource management and CPU scheduling and the Linux kernel tuning guide.

Changelog and Last Updated

Initial publication. Last updated: September 26.