How to Check Load Average in Linux: A Complete Guide

You know that sinking feeling when someone messages you at 2 AM saying “the server feels slow”? The first thing I do—before coffee, before even fully opening my eyes—is check the load average. It’s the quickest way to know if you’re dealing with a minor hiccup or a genuine crisis.

After a decade of managing Linux systems, I’ve learned that load average tells a story. Not just about CPU usage (that’s a common misconception), but about the overall demand on your system. Let me show you exactly how to check it and what those numbers actually mean.

What is Load Average and Why It Matters

Load average represents the average number of processes that are either running on the CPU or waiting for resources—typically CPU time or I/O operations. Unlike a simple CPU percentage, load average gives you a sense of how backed up your system is.

Here’s what most tutorials get wrong: load average isn’t just CPU usage. On Linux, it includes processes in both the runnable state (actively using or waiting for CPU) and the uninterruptible sleep state (usually waiting for disk I/O). This is actually unique to Linux—other Unix systems only count runnable processes.

That’s why you might see high load averages but relatively low CPU usage. Your processes aren’t hammering the processor; they’re stuck waiting for slow disk operations.

The Three Numbers Explained

When you check load average, you’ll see three numbers like 1.45, 0.98, 0.63:

• First number: Average load over the last 1 minute
• Second number: Average load over the last 5 minutes
• Third number: Average load over the last 15 minutes

The 1-minute average shows what’s happening right now. The 15-minute average gives context about the recent past.

The Fastest Way: Using the uptime Command

The quickest way to check load average is with the uptime command:

uptime

You’ll get output like this:

14:23:45 up 23 days,  4:17,  3 users,  load average: 0.52, 0.58, 0.63

I use uptime constantly—it’s the first command I run when SSH’ing into a server to investigate an issue. It’s fast, simple, and immediately tells me if the system is under stress.

Real-Time Monitoring with top and htop

While uptime gives you a snapshot, top gives you a live view that updates every few seconds:

top

The top line shows your load average along with other useful information. What I love about top is that it also shows you which processes are consuming resources. If your load is high, you can immediately see the culprit. For detailed CPU analysis, check out my guide on how to check CPU usage in Linux.

Understanding Process States

In top, look at the S column (process state):

• R – Running or runnable (on the run queue)
• D – Uninterruptible sleep (waiting for I/O)
• S – Sleeping (waiting for an event)

Both R and D states contribute to load average. If you’ve got processes stuck in the D state, they’re waiting for disk or network I/O, not CPU time. This is often the source of high load with low CPU usage.

The Better Option: htop

If top is a dashboard, htop is a dashboard designed for humans. It’s colorful, interactive, and easier to parse:

htop

Install it with:

sudo apt install htop  # Debian/Ubuntu
sudo dnf install htop  # RHEL/Fedora

Reading /proc/loadavg Directly

Linux stores load average in a special file:

cat /proc/loadavg

You’ll get output like 0.52 0.58 0.63 2/347 12849. The first three numbers are your load averages. The fourth value shows running processes over total processes. This is helpful when writing scripts or automation.

What’s a “Good” Load Average?

This is the million-dollar question, and the answer is: it depends on your CPU core count.

A load average of 1.0 means one process was demanding resources at all times. On a single-core system, that’s 100% utilization. On a quad-core system, that’s only 25%.

Here’s my rule of thumb:

• Below your core count: You’re good. The system has headroom.
• Equal to your core count: You’re at capacity, but not overloaded.
• Above your core count: Processes are waiting. Time to investigate.

On a single-core system, I start paying attention above 0.70. Once it crosses 1.0, I’m actively investigating. If it hits 5.0, something is seriously wrong.

How to Check Your CPU Core Count

Check how many cores you have:

nproc

Or for more detail:

lscpu | grep "^CPU(s):"

Troubleshooting High Load Average

So your load average is through the roof. Now what?

Check If It’s CPU-Bound

Open htop or top and look at the CPU bars. Are they maxed out? If yes, you’ve got a CPU-bound problem. Common culprits: runaway scripts, infinite loops, poorly optimized database queries.

Check If It’s I/O-Bound

If CPU usage looks reasonable but load is high, you’re probably waiting on I/O. In top, look at the “wa” (wait) percentage:

%Cpu(s):  5.2 us,  2.1 sy,  0.0 ni, 72.3 id, 20.1 wa,  0.0 hi,  0.3 si,  0.0 st

That 20.1 wa means 20% of CPU time is spent waiting for I/O. If this number is high, your disk or network is the bottleneck.

Use iostat to see which disks are busy:

iostat -x 1

Or use iotop to see which processes are hammering your disks:

sudo iotop

I’ve seen load averages spike to 15+ on systems with fine CPU usage, all because a backup job was saturating the disk. Understanding the difference between CPU load and I/O wait is critical.

Check Memory Pressure

Sometimes high load is caused by the system thrashing—constantly swapping data between RAM and disk:

free -h

If your swap usage is high and constantly changing, you’re memory-constrained. Read my guide on how to check memory usage in Linux for more details.

Look for Stuck Processes

If you have processes stuck in uninterruptible sleep (D state), they’re contributing to load average but not actually doing work:

ps aux | awk '$8 ~ /D/ {print $0}'

Common causes: failed NFS mounts, dying hard drives, or buggy device drivers. If you’re investigating which resources these processes are waiting on, lsof is your friend.

Monitoring Load Average Over Time

Using watch for Continuous Updates

Keep an eye on load average without constantly rerunning commands:

watch -n 5 uptime

This runs uptime every 5 seconds. I use this when I’ve made a change and want to see if load drops.

Long-Term Monitoring with sar

For historical data, sar (System Activity Reporter) is invaluable:

sudo apt install sysstat  # Debian/Ubuntu
sudo dnf install sysstat  # RHEL/Fedora

View historical load averages:

sar -q

This shows load average data collected over the past day. Historical load data has saved me countless times during troubleshooting.

Real-World Troubleshooting Examples

The Runaway Cron Job

I got paged at 3 AM because a web server’s load average hit 12 on a 2-core system. I ran htop and saw the problem: a backup script had spawned 40 concurrent rsync processes. Killed the parent process, fixed the script, and load dropped to normal within seconds.

The Slow Disk

Load average was 6 on a 4-core machine, but CPU usage was only 15%. Classic I/O wait situation. Ran iostat and saw one disk with 100% utilization. A failing drive was causing the RAID array to struggle. Replaced the drive, and everything went back to normal.

The Memory Leak

Load average crept up slowly over several days. Checked CPU: normal. Checked I/O: normal. Checked memory: swap was maxed out and constantly churning. A Java application had a memory leak, forcing constant swapping. Restarted the application, and load immediately dropped. If you’re seeing unusual service behavior, check your systemd service status for clues.

Quick Reference: Essential Commands

Final Thoughts

Load average is one of the first things I check when troubleshooting, but it’s never the only thing. It’s a starting point that tells you the system is under stress, but you need to dig deeper to understand why.

After checking load average, I typically move on to CPU usage, memory consumption, disk I/O, and maybe even system logs with journalctl to get the full picture.

Master the basics of checking load average, understand what the numbers mean in context, and you’ll be way ahead when it comes to keeping your Linux systems healthy and responsive.