uptime prints something like this:

 14:32:07 up 41 days,  3:12,  2 users,  load average: 0.84, 1.20, 1.05

The three load average numbers are among the most quoted and most misread metrics on a Linux server. Here’s what they really measure, and when you should worry.

What load average measures

Load is the average number of processes that are:

  • running on a CPU,
  • waiting for a CPU (runnable), or
  • in uninterruptible sleep (state D), usually waiting for disk I/O.

The three numbers are averages over the last 1, 5 and 15 minutes, exponentially weighted. Read them as a trend:

  • 0.8, 1.2, 1.0 — fairly steady.
  • 6.5, 2.1, 0.9 — load rising now.
  • 0.5, 2.8, 4.1 — a busy period that is ending.

Compare load to the number of cores

Load has no fixed scale. It only means something relative to the number of CPU cores:

nproc
Load ÷ cores Meaning
< 0.7 Comfortable headroom
≈ 1.0 Fully used: processes rarely wait
> 1.0 Processes are queueing for CPU or I/O
≫ 1 (e.g. 3×) Saturated: expect slow responses

A load of 4.0 is fine on an 8-vCPU server and heavy on a 2-vCPU server. Brief spikes during deployments, backups or cron jobs are normal. Sustained load above the core count is what matters.

High load isn’t always CPU

Because load includes processes waiting on disk (state D), a server can have high load and an idle CPU. Check which it is:

top

Look at the %Cpu(s) line:

%Cpu(s): 12.0 us,  3.0 sy,  0.0 ni, 40.0 id, 45.0 wa,  0.0 hi,  0.0 si,  0.0 st
  • us/sy high → CPU-bound: application or kernel work.
  • wa high → waiting on disk. That suggests heavy I/O: a database without enough RAM for its cache, swapping, backups or log storms.
  • st high → steal time: the hypervisor is giving your VPS’s CPU time to other guests.

Then dig deeper:

vmstat 1 5          # r = runnable, b = blocked on I/O, si/so = swapping
iostat -xz 1 3      # per-disk utilisation and latency
ps -eo state,pid,cmd | awk '$1=="D"'      # processes stuck in I/O wait

See vmstat, iostat and htop.

Common causes of high load on a VPS

Symptom Likely cause Fix
High us, one process at the top Busy app, a runaway script, crypto-mining malware Optimise, add caching, investigate unknown processes
High wa, si/so > 0 in vmstat Out of RAM, swapping Reduce memory use or add RAM
High wa, no swapping Heavy disk I/O (DB queries, backups) Index queries, give the DB cache more RAM, schedule backups off-peak
Many PHP-FPM or Apache workers Traffic spike or bots Caching, rate limiting, tune workers
High st Noisy neighbours, CPU oversubscription Contact the provider, or move to a bigger plan or dedicated server

Check memory with free, and look for bots in access logs with sort and uniq.

Other places to read load

cat /proc/loadavg
# 0.84 1.20 1.05 2/389 123456

The fourth field is currently runnable processes / total processes, and the fifth is the last PID.

w shows load plus logged-in users. top and htop show it in their headers.

uptime itself

uptime -p          # up 5 weeks, 6 days, 3 hours
uptime -s          # 2026-09-03 11:20:14 (boot time)

A recent, unexpected boot time is worth investigating, especially if the server shouldn’t have rebooted. Check journalctl --list-boots and the logs from the previous boot (journalctl -b -1 -e).

Monitor it over time

A single reading tells you little. Graph load alongside CPU, memory and disk I/O with a monitoring tool such as Netdata or Prometheus and Grafana, and alert on sustained load (for example, the 15-minute average above the core count for 10 minutes).

Quick reference

Task Command
Load + uptime uptime
Cores nproc
CPU breakdown (us/wa/st) top
Runnable vs blocked vmstat 1
Disk pressure iostat -xz 1
Boot time uptime -s

Related: top and ps.

  • Linux
  • Performance
  • Monitoring