What does Linux load average actually measure?

Load average is the average number of processes that are either actively running on a CPU or waiting for CPU time, plus (on Linux) processes in uninterruptible I/O wait. It is NOT a percentage. A load of 4.0 means 4 processes are competing for CPU resources at any given moment. The three numbers represent exponentially-damped moving averages over 1, 5, and 15 minute windows.

What is a good load average for my server?

Load average should be interpreted relative to CPU core count. A load below 70% of your core count (e.g., below 2.8 on a 4-core machine) means comfortable headroom. A load equal to core count means all CPUs are busy with no queue. A load above core count means processes are waiting. For production servers, aim to stay below 70% of core count to handle traffic spikes.

What do the three load average numbers (1, 5, 15 minute) mean?

The three numbers show system load trends over different time windows. The 1-minute average reacts quickly to changes and shows current demand. The 5-minute average smooths out brief spikes. The 15-minute average shows the longer trend. If 1-min is much higher than 15-min, load is increasing. If 1-min is lower than 15-min, the system is recovering from a spike.

Why is load average high but CPU usage is low?

On Linux, load average includes processes waiting for disk I/O (in 'D' uninterruptible sleep state), not just CPU. High load with low CPU usage typically indicates a disk bottleneck: slow storage, NFS timeouts, or heavy swapping. Check with 'iostat -x 1' for disk utilization and 'vmstat 1' for I/O wait percentage.

Load Average Interpreter

What those three numbers from uptime actually mean for your server.

What load average actually measures

Load average is not CPU percentage. It's the average number of processes that are either running on a CPU or waiting for one (plus, on Linux, processes waiting for disk I/O). The three numbers represent the average over 1, 5, and 15 minutes.

On a 4-core system, a load average of 4.0 means every core is busy but nothing is waiting. A load of 8.0 means every core is busy and 4 processes are queued. A load of 1.0 means 75% of your capacity is idle.

The number that matters is load relative to your core count. A load of 16.0 is fine on a 32-core machine. A load of 2.0 might be a problem on a single-core VPS.

How to find your CPU core count

OS	Command
Linux	nproc
Linux (alt)	grep -c ^processor /proc/cpuinfo
macOS	sysctl -n hw.ncpu
FreeBSD	sysctl -n hw.ncpu

These return logical CPUs (including hyper-threads). That's the right number to use for load average comparison.

Physical cores vs vCPUs: a machine with 2 physical cores and hyper-threading reports 4 vCPUs, but it's not the same as 4 physical cores. Hyper-threading shares execution units between threads and typically adds 15-30% throughput, not 100%. A load of 4.0 on a 2-core/4-thread machine is under more real pressure than the same load on a true 4-core. The scheduler treats each thread as a unit, so nproc is still the right denominator, just know that maxing out vCPUs hits harder when half of them are hyper-threads.

Load average vs CPU utilization

High load, low CPU

Processes are waiting for I/O, not CPU. Typical cause: slow disks, NFS mounts, or swapping. The CPUs are mostly idle but the system feels sluggish because everything is blocked on disk. Check iostat and vmstat for wait states.

Low load, high CPU

A few processes are using a lot of CPU but the run queue is short. Single-threaded workloads on multi-core systems. The system isn't overloaded, it's just one core doing all the work.

High load, high CPU

The system is genuinely busy. This is fine if load is at or below core count. Above core count means processes are queuing. Check if it's sustained or a burst.

Linux-specific: unlike other Unix systems, Linux includes processes in uninterruptible sleep (D state) in load average. This means disk-bound workloads inflate the number. A load of 8.0 on a 4-core Linux box might just mean heavy I/O, not CPU saturation.

What to do when load is high

1.

Check what's running. top sorted by CPU (press P) or htop. Look for runaway processes, stuck workers, or unexpected cron jobs piling up.

2.

Check I/O wait. iostat -x 1 or look at wa% in top. High I/O wait with low CPU means the disk is the bottleneck, not the processor.

3.

Check memory and swap. free -h. If the system is swapping heavily, load will spike because disk I/O is orders of magnitude slower than RAM. Fix the memory problem first.

4.

Look at the trend, not just the snapshot. A spike to 10x capacity for 30 seconds during a deploy is different from sustained 2x capacity for hours. The 15-minute average tells you if this is persistent.

See it over time. fivenines.io tracks load average continuously and alerts you to trends before they become problems. A slow upward drift over days is easy to miss in a terminal, obvious on a graph.

The Three Load Average Numbers Explained

When you run uptime or cat /proc/loadavg, you see three numbers like 2.50 1.80 0.90. These are exponentially-damped moving averages over 1, 5, and 15 minute windows.

The 1-minute average is the most reactive. It shows what's happening right now. A sudden spike here means something just started consuming resources. This is the number to watch during active troubleshooting.

The 5-minute average smooths out brief spikes. If the 1-minute number is high but the 5-minute is normal, you're probably seeing a short burst that will pass. Useful for filtering out noise from cron jobs or deployment processes that temporarily spike load.

The 15-minute average tells the bigger story. If this number is high, the system has been under pressure for a while and it's not going away on its own. This is the one to use for capacity planning decisions.

Reading the three together tells you the trend. If the numbers are 8.0 4.0 2.0 (high to low, left to right), load is spiking and getting worse. If they're 2.0 4.0 8.0 (low to high), the system is recovering from something that already happened. If all three are similar, load is stable.

When High Load Average Is Actually Fine

Not every high load number is a fire. Context matters more than the raw value.

Batch processing and builds. A CI/CD server compiling code or a data pipeline crunching numbers will show high load while working. If the jobs finish on time and the server isn't user-facing, load at 100% of core count is just the machine earning its keep.

I/O-heavy workloads on Linux. Remember that Linux counts processes waiting on disk I/O in the load average. A database server running large sequential scans will show high load even though the CPUs might be mostly idle. Check wa% in top to see if I/O wait is the cause. If it is, adding CPU won't help; you need faster storage.

Short spikes during known events. A load spike during deployment, log rotation, or backup windows is expected. What matters is whether the system recovers afterward. Look at the 15-minute average: if it stays elevated long after the event, something else is going on.

The real question is always: "are users or services affected?" A load of 10x on a batch server with no SLA is fine. A load of 1.5x on a latency-sensitive API server is a problem. Use load average as a signal, not a verdict, and always correlate with actual response times and error rates.

Related Resources

Server Alerting & Notifications -Set load average thresholds and get alerted when your server is under pressure
SLA Uptime Calculator -Understand how performance degradation impacts your uptime commitments
Disk Space Calculator -Check if I/O-related load is a disk capacity issue
Custom Monitoring Dashboards -Track load average, CPU, memory, and disk on a single screen

Track load average trends, not just snapshots

Start monitoring with fivenines.io