Load Average: Explanation & Insights

Three numbers that tell you how many tasks wanted the machine, not how busy it was.

What It Is

Load average is the three numbers that greet you at the top of uptime, top, and the first line of every server you log into:

uptime

 19:30:30 up 2 days, 22 min,  1 user,  load average: 2.82, 1.71, 0.83

Those three figures — 2.82 1.71 0.83 — are the average demand on the system over the last 1, 5, and 15 minutes, in that order. Read left to right, they're a tiny graph of where the machine has been heading: rising means it's getting busier, falling means a storm is passing, flat means steady state. The raw source sits in a file you can read with no tools at all, which is where every program ultimately gets it from:

cat /proc/loadavg

2.82 1.71 0.83 5/2278 698183

The first three columns are the load averages; the rest are a bonus we'll come back to. So far this looks straightforward, and most tutorials stop here with "it's how busy the CPU is." That sentence is wrong, and getting it wrong is the single most expensive mistake people make reading this number. The whole point of this page is to replace it with something true: load average measures demand, not usage — how many tasks wanted the machine, regardless of whether the machine was even the thing holding them up. A server can show a load of 50 with its CPUs almost entirely idle. By the end of this page you'll understand exactly how, and why that matters more than any other fact about load.

This is also CleverUptime's headline metric — the first number we read on every box, every minute — so it's worth getting all the way to the bottom of it.

Why It Matters

Load average is the closest thing a server has to a pulse. One number (well, three) and you know, in a glance, whether the machine is asleep, comfortably busy, or drowning. It's the first thing a seasoned admin looks at when something feels wrong, and it has been for fifty years, because it answers the only question that matters in the first three seconds of an incident: is this box keeping up, or has work started to pile up faster than it can clear it?

But the reason it matters is the same reason it misleads. Load is a count of a queue — and a queue forms whenever tasks want something they can't have yet. Usually that something is a CPU core. Sometimes it's a disk that's answering too slowly, or a dead network mount that will never answer at all. Load average folds all of those into one figure without telling you which is which. So the metric that's brilliant for noticing trouble is treacherous for diagnosing it — and the gap between those two jobs is where careers' worth of wasted afternoons live. Learn to read load as a question rather than an answer ("something is queuing — for what?") and you've learned the most important thing on this page.

There's a second reason it matters, the cheerful one: load tells you when you're overpaying. A box that has sat at a load of 0.1 for a month is a box several sizes too big. On a startup's monthly bill that's real money, and the three numbers are the receipt.

What Load Actually Counts

To read load average you have to know precisely what goes into it, and here Linux does something specific — and, for once, genuinely peculiar — that no other operating system does. Hold that thought; it's the crux.

Every task on the machine — every process and thread — is, at any instant, in one of a handful of states. Most are sleeping: parked, waiting for a request to arrive, a timer to fire, a keystroke. A sleeping web worker at 3 a.m. costs nothing and counts toward nothing. The states that do count are:

Running or runnable (R) — the task is either on a CPU core right now or sitting in the run queue, ready to go the instant a core frees up. This is the obvious half of load: things that want to compute and are waiting their turn.
Uninterruptible sleep (D) — and this is the Linux twist. A task in D state is blocked inside the kernel, waiting on something it cannot be woken from until that something completes — almost always disk I/O, or a stuck network filesystem. You can't even kill a D-state task; not kill -9, not anything, until its I/O returns.

Classic Unix counted only the first group: load was the run queue, pure and simple — tasks competing for CPU. Linux made a deliberate, fateful choice early on to count D-state tasks too. The reasoning was sound: a machine where forty processes are frozen waiting on a hung disk is not a healthy machine, and a metric that reported load 0.0 while the box was unusable would be lying by omission. So Linux folded "blocked on I/O" into the same number as "waiting for CPU."

The consequence is the thing every other tutorial fumbles. On Linux, load average is not a CPU metric. It's a "tasks that wanted to make progress and couldn't" metric — and "couldn't" includes both no free core and the disk hasn't answered yet. That single design decision is why a load of 50 can sit on top of 95%-idle CPUs (see iowait for the full story of that idle-but-blocked state). It's the most counterintuitive fact in Linux performance, and once it clicks, half the mysteries of high load dissolve.

Note

The last two fields of /proc/loadavg — 5/2278 and 698183 in the reading above — aren't load at all. The 5/2278 is "kernel scheduling entities runnable right now / total that exist," and the final number is the most recently created PID. Useful trivia, occasionally a quick sanity check, but it's the first three numbers that everyone means by "load average."

The Three Time Windows

Why three numbers instead of one? Because a single instantaneous reading would be useless noise — load spikes and dips by the millisecond as tasks wake and sleep. The three windows turn that noise into a trend you can actually read.

The 1-minute figure reacts fast. It's twitchy — a brief burst of work moves it sharply, and it falls just as quickly when the burst ends. It tells you what the machine is doing right now.
The 5-minute figure is the middle ground, smoothing over short blips while still tracking real changes.
The 15-minute figure is the long memory. It barely flinches at a momentary spike; it only climbs when load has been genuinely sustained. It tells you the baseline, the weather rather than the gust.

Read together as 1min 5min 15min, the order of the three numbers is a direction:

Rising (5.00 3.00 1.00) — the 1-minute is highest, so demand is climbing and it's recent. Fifteen minutes ago this box was nearly idle; now it's at 5 and accelerating. Something just started, and it isn't finished escalating. This is the pattern that means go look now, before it becomes the incident.
Falling (1.00 3.00 5.00) — the mirror image. The 15-minute is highest, so it was busy and it's clearing on its own. If someone says "the site was slow ten minutes ago," this reassures you it's already recovering.
Steady (3.90 4.00 3.80) — all three close together is a machine in equilibrium, handling a consistent workload at a consistent pace. Whether that's healthy depends entirely on the core count, which is the next, and most important, piece.

Always Divide By the Core Count

Here is the rule that makes load average legible, and the one half of all online advice gets wrong: a load number means nothing until you divide it by the number of cores. Load is an absolute count of tasks wanting the machine; capacity is the number of cores ready to serve them. The ratio between them — call it load per core — is the figure that actually tells you how the box is doing.

Count your cores first. The kernel reports the logical CPU count with nproc:

nproc

Now the same load number tells three completely different stories depending on what it lands on:

Load 8 on an 8-core box → load per core is 1.0. Every core has, on average, exactly one task wanting it. The machine is fully used and keeping up — no queue building, no idle waste. This is what "good and busy" looks like, and it should not alarm you one bit.
Load 8 on a 2-core box → load per core is 4.0. Four times as many tasks want a core as there are cores. Three out of every four are always waiting in line; everything feels sluggish. This box is in trouble.
Load 8 on a 32-core box → load per core is 0.25. The machine is loafing. Twenty-four cores are idle. It's a quiet afternoon, and if it's always this quiet you're renting far more server than you need.

Same 8, three verdicts. The number on its own is meaningless; the number per core is everything. This is why the very first reflex when you see a load average should be to ask "and how many cores does this box have?" — and why a monitoring tool that shows you load without normalizing it is handing you a thermometer with no scale.

Pro Tip

The logical core count from nproc includes hyperthreads — Intel's and AMD's trick (SMT) of presenting one physical CPU core as two logical ones. A hyperthread isn't a full core; it buys maybe 15–30% extra throughput, not 100%. So a load sitting right at your nproc number is a touch more loaded than the clean "one task per core" math suggests. Don't panic over it — just know that nproc slightly flatters you.

Demand, Not Usage — and Why a High Number Isn't Always Bad

This is the heart of the page, so let's slow down and nail it once and for all. Load average and CPU usage are two different animals answering two different questions.

CPU usage is a utilisation figure: what fraction of the time the cores spent actually computing. It's capped at 100% per core. It answers "how hard did the engines work?"
Load average is a demand count: how many tasks wanted to make progress. It is not capped — it can be 5, or 50, or 500. It answers "how long was the line?"

You need both because they fail apart in exactly the situation that matters most. Picture a load of 8 on an 8-core box. That's load per core 1.0 — but it could be either of two utterly different machines:

Eight tasks pinned to eight cores, all computing flat out. CPU usage near 100%, iowait near zero. This is genuine CPU saturation — real work, and if it's sustained, scaling out or up will actually help. The cores are the bottleneck.
Eight tasks all stuck in D state, blocked on a failing disk or a dead NFS mount, computing nothing. CPU usage near zero, iowait high, cores sitting on their hands. The same load of 8, and a bigger server would do absolutely nothing — you'd just have more idle cores waiting on the same broken disk.

Same load, same core count, same "load per core of 1.0" — and the correct response is the opposite in each case. That's why the load number alone can never be the diagnosis. The instant you see an unhealthy load, the question is never "how do I lower this number" but "what are these tasks waiting on?" Waiting on CPU is a capacity problem. Waiting on I/O is a disk or network problem with idle CPUs, and reaching for more cores is throwing money at the wrong wall.

The most memorable version of this I've watched in the wild: a box showing a load near 100, every alarm screaming — and the CPUs were practically asleep. A directory had been mounted over a network filesystem, the link dropped, and every process that so much as glanced at that mount froze in D state waiting for a reply that was never coming. They stacked up, load sailed past 100, and the machine wasn't computing a thing. The cure wasn't a bigger server; it was fixing the mount. Load counted everyone waiting, exactly as designed — it just wasn't waiting on what the panic assumed.

So the discipline is simple and it never changes: read load to notice, then read the breakdown to diagnose. Load says "something's queuing"; top's %Cpu(s) line (or vmstat, or mpstat) says whether it's queuing for compute or for I/O.

The Exponential Decay — Why 1-Minute Reacts and 15-Minute Smooths

It's worth understanding how the three windows are computed, because the mechanism explains exactly why they behave the way they do — and it's a small, satisfying piece of engineering.

You might assume the "1-minute average" is the kernel storing sixty seconds of samples and averaging them. It isn't — that would mean keeping a rolling buffer of history for every window, which is wasteful. Instead each of the three numbers is an exponentially weighted moving average, and the kernel keeps just one running number per window. Every five seconds it samples the current run-queue length and nudges each average a little toward that sample:

new_average = old_average × decay + current_sample × (1 − decay)

The whole trick lives in decay. The 1-minute average uses a decay close to... well, it's tuned so that older readings fade quickly; the 15-minute average uses a decay much closer to 1, so each new sample barely moves it and old readings linger for a long time. "Exponentially weighted" means the influence of any given sample shrinks by a constant factor every step into the past — recent readings count for a lot, the reading from a minute ago counts for less, the reading from ten minutes ago counts for almost nothing. There's no hard cutoff at "one minute"; the name is shorthand for "weighted so that it mostly reflects roughly the last minute."

That's why the 1-minute figure is twitchy and the 15-minute figure is sluggish: the 1-minute throws away the past quickly, so a fresh burst dominates it almost immediately, while the 15-minute clings to its history, so the same burst barely registers until it's been going for a while. The smoothing isn't a quirk — it's the entire reason the three numbers are useful as a trend instead of three copies of the same noisy instant. One running number, one multiply-and-add every five seconds, and you get a metric that distinguishes a momentary hiccup from a sustained problem. Not bad for arithmetic a calculator could do.

Why

If you've met exponential moving averages before, it was probably in finance — the same maths smooths stock prices into trend lines. The kernel reached for it for the same reason a trader does: you want recent events to matter more than ancient ones, without the cost of remembering every event. The run queue and the S&P 500 turn out to want the same statistical trick.

Reading It by Example

The fast way to build instinct is to read real numbers against a real core count. Assume an 8-core box unless noted, and remember the three figures are 1, 5, 15 minutes.

load average: 0.52 0.48 0.45 on 8 cores → load per core ~0.06. Nearly idle, and steadily so. Healthy — but if it's always this low, you're paying for an instance several sizes too big. Drop down and pocket the difference.
load average: 7.80 8.10 7.90 on 8 cores → load per core ~1.0, steady. A well-sized box doing real work and keeping up. Busy-looking numbers, but this is exactly what "good" looks like. Don't let it scare you.
load average: 16.00 15.00 14.00 on 8 cores → load per core ~2.0, sustained. Twice as many tasks want the machine as it can serve at once. This is the threshold where it's actively hurting — go find out what, and whether it's CPU or I/O.
load average: 30.00 18.00 9.00 on 4 cores → load per core climbing past 7 and accelerating (1-min far above 15-min). Something started recently and is escalating fast. Don't wait for it to plateau.
load average: 95.00 70.00 40.00 on 8 cores with CPUs ~idle → the I/O trap. A load this high with low CPU usage and high iowait is not a compute problem — it's tasks piling up in D state on a slow or failing disk, or a hung mount. A bigger CPU buys you nothing. Chase the storage. (A genuine runaway process or fork storm reaches load 100 too — but that one shows the CPU pegged, not idle, which is how you tell them apart in five seconds.)

How I Inspect It

Over the shoulder, the order of glances when a box feels wrong:

uptime or the top line of top first — read the three numbers, note the trend (rising / falling / steady). It's everywhere, it's instant, it never lies about demand.
nproc immediately after — divide the load by the core count. Until I've done this division I don't actually know anything. Load per core is the real reading.
top's %Cpu(s) line — now the crucial fork. If wa (iowait) is high, the queue is waiting on the disk and I stop thinking about CPU entirely. If us/sy are high and wa is near zero, it's genuine compute demand.
vmstat 1 when I want the cleanest single screen for this exact question — its r column is the run-queue length (tasks waiting on CPU) and its b column is tasks blocked on I/O, side by side. Watching r versus b tells you in one glance which half of the load is which, refreshed every second.
mpstat -P ALL 1 for the per-core breakdown — to catch the single-threaded trap, where one core is pinned at 100% and the rest idle, which keeps total load low while one program is maxed out.
top process list to name the culprit, and ps to confirm what state it's in (R vs D).

The whole sequence is one habit: never trust the load number until I've divided it by cores and asked what the queue is waiting on.

Cheat Sheet

# --- Read it ---
uptime                 # the three numbers, plus how long the box has been up
cat /proc/loadavg      # the raw source: load1 load5 load15 running/total lastpid
top                    # load on line 1, live, plus the %Cpu(s) breakdown
w                      # like uptime, plus who's logged in and what they're running

# --- Normalize it ---
nproc                  # logical core count — ALWAYS divide load by this
lscpu                  # cores vs threads (so you know how many are 'real')

# --- Diagnose what the queue is waiting on ---
vmstat 1               # 'r' = waiting on CPU, 'b' = blocked on I/O — the key split
mpstat -P ALL 1        # per-core usage; catches one-core-pinned single-threaded apps
top                    # %Cpu(s): high 'wa' = disk-bound, high 'us'/'sy' = CPU-bound
ps -eo state,pid,comm | grep '^D'   # list the uninterruptible-sleep tasks inflating load

Rules of thumb, stated plainly (and opinions, not hedges):

Load per core sustained above 1 → investigate. Tasks are starting to queue. Not yet an emergency, but worth knowing why.
Load per core sustained above 2 → it's hurting. Twice the demand the cores can serve; users feel it.
Read the trend, not the instant. A 1-minute spike that the 15-minute hasn't caught up to is often just a passing burst. Sustained is what counts.
Always pair load with wa. High load + high iowait = a storage problem, not a CPU one. This single check saves the most wasted hardware spend of any habit on this page.

History and Philosophy

Load average is older than Linux, older than Unix's spread to the wider world — it comes from the timesharing mainframes of the late 1960s and early 1970s, where a dozen people shared one machine over teletypes and the operator needed to answer, at a glance, "is this thing keeping up or am I about to get complaints?" Three numbers on a printed line answered it without a manual. That ruthless economy of attention is why the same three numbers still lead every server you log into more than fifty years later. A metric that survives that long isn't lucky; it's solving a problem that never went away.

The exponentially-weighted-average machinery came along to turn a jittery instantaneous count into a readable trend, and the choice of 1, 5, and 15 minutes is itself a piece of human-factors wisdom: short enough to catch a developing problem, long enough to ignore the noise, three windows so the shape of the trend is visible in a single line. There's no committee-designed dashboard in that — just decades of operators wanting to know one thing fast.

Then there's Linux's own contribution, the D-state decision we met earlier — and it has a documented origin worth knowing. In 1993 a kernel developer named Matthias Urlichs noticed that load average ignored processes blocked on uninterruptible I/O, which meant a machine grinding to a halt on a slow disk could report a deceptively calm load. He patched the kernel to count them, with a now-famous comment to the effect that this was what people expected load to mean even if it wasn't the textbook definition. That patch is why Linux's load average measures "system busyness" in the broadest sense rather than the strict academic "run-queue length" — a pragmatic redefinition that has confused newcomers and helped admins ever since. It's the rare case where the "wrong" answer turned out to be the more useful one, and it stuck because it was right about what humans actually wanted to know.