---
type: Article
title: "SNMP System Load Monitoring"
description: "Load average is the one number that says whether a server is keeping up. Read the 1-, 5- and 15-minute figures over SNMP, and why it beats CPU percentage."
resource: "https://snmp-monitoring.com/sensors/server-resources/system-load/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# SNMP System Load Monitoring

The SNMP load average is the single number that best summarizes whether a Unix or Linux server is keeping up with what's being asked of it. It's the metric behind the top-left corner of `top` and `uptime`, and SNMP exposes it cleanly so you can graph it, trend it, and alert on it without ever logging in. This guide covers what load average really measures, the exact vendor OID that returns it, how to read the one-, five-, and fifteen-minute figures, how it differs from CPU percentage, and why reading it from outside the machine is what turns a chart into an early-warning system.

## What is System Load and why monitor it

Load average is the average number of processes that are either running or waiting to run over a rolling window. Unix reports three figures — averaged over the last 1, 5, and 15 minutes — and the interplay between them tells a story a single snapshot can't. A load of 4.00 on a four-core machine means, roughly, that the CPUs are fully committed with nothing queued behind them; the same 4.00 on a single-core box means processes are stacked four deep, waiting their turn.

That's the first rule of reading it: load is only meaningful relative to core count. Divide the figure by the number of cores. Below 1.0 per core, there's headroom. Around 1.0 per core, the machine is fully utilized. Well above 1.0 per core and sustained, work is backing up faster than the server can clear it.

Why monitor system load specifically? Because it captures pressure that pure CPU percentage misses. On Linux, load also counts processes blocked in uninterruptible I/O wait — so a server drowning in slow disk or a stuck NFS mount shows a high load average even while the CPUs look idle. That divergence is diagnostic gold. High load with low CPU points straight at I/O; high load with high CPU points at compute. The symptom users feel is the same either way: sluggish response, timeouts, requests queuing. The load average sees it coming.

![Diagram of an external SNMP poller reading the laLoad system-load OID from a server's agent over UDP](https://snmp-monitoring.com/img/sensors/snmp-load-average-poll.webp)

## The OID: 1.3.6.1.4.1.2021.10.1.3 (UCD/net-snmp, vendor-private)

The load average OID is `1.3.6.1.4.1.2021.10.1.3`, named `laLoad`, and it lives in the UCD-SNMP-MIB. This one is important to flag: `1.3.6.1.4.1.2021` is the Net-SNMP (former UCD-Davis) enterprise branch — a *vendor* MIB, not an IETF standard. There's no RFC for it. It's ubiquitous because Net-SNMP is ubiquitous, but a switch or appliance that doesn't run Net-SNMP won't necessarily publish it.

`laLoad` is a small table with three rows, one per averaging window:

| OID | Object | Window | Value |
|---|---|---|---|
| `1.3.6.1.4.1.2021.10.1.3.1` | `laLoad.1` | 1-minute | Load average as a string |
| `1.3.6.1.4.1.2021.10.1.3.2` | `laLoad.2` | 5-minute | Load average as a string |
| `1.3.6.1.4.1.2021.10.1.3.3` | `laLoad.3` | 15-minute | Load average as a string |

So the base OID `1.3.6.1.4.1.2021.10.1.3` is the column, and the final digit selects the window: `.1` for the 1-minute figure, `.2` for 5-minute, `.3` for the 15-minute average. The value comes back as a display string like "0.42" rather than a scaled integer, which is convenient to read but means your poller parses it as a float.

Don't confuse `laLoad` with CPU utilization. They answer different questions — see the note below and the [CPU monitoring page](/sensors/server-resources/cpu-utilization.md) for the percentage metric at `hrProcessorLoad`.

## How to query it

Any Net-SNMP client reads this instantly. These examples assume an SNMPv2c agent with a read-only community; if that's not configured, the [snmpd.conf guide](/setup/snmpd-conf.md) covers it.

1. **Walk all three load averages** at once:
   ```bash
   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.4.1.2021.10.1.3
   ```
   ```
   UCD-SNMP-MIB::laLoad.1 = STRING: 0.42
   UCD-SNMP-MIB::laLoad.2 = STRING: 0.55
   UCD-SNMP-MIB::laLoad.3 = STRING: 0.60
   ```
2. **Read just the 15-minute figure** — the least twitchy one for alerting:
   ```bash
   snmpget -v2c -c public 10.0.0.5 1.3.6.1.4.1.2021.10.1.3.3
   ```
   ```
   UCD-SNMP-MIB::laLoad.3 = STRING: 0.60
   ```
3. **Force numeric output** if the UCD-SNMP-MIB isn't installed locally:
   ```bash
   snmpwalk -v2c -c public -On 10.0.0.5 1.3.6.1.4.1.2021.10.1.3
   ```

Pull all three windows and you can tell direction at a glance: if the 1-minute figure sits well above the 15-minute, load is rising; if it's below, the spike is passing.

## Normal vs alarming values & thresholds

Every threshold below is *per core* — always normalize by dividing the raw load by your core count before comparing:

- **Under 0.7 × cores, sustained** — healthy. Plenty of headroom.
- **0.7–1.0 × cores** — busy but coping; a reasonable warning band.
- **Around 1.0 × cores, sustained** — fully committed. No spare capacity; new work starts queuing.
- **Above 1.5–2.0 × cores, sustained** — overloaded. Latency is almost certainly degrading; treat as high priority.
- **Brief spikes on the 1-minute figure** — usually harmless (a cron job, a deploy). Alert on the 5- or 15-minute window instead so momentary blips don't page you.

Two habits keep these alerts honest. Alert on the longer windows for anything that pages a human — the 1-minute figure is too noisy on its own. And cross-reference: high load with idle CPU means I/O wait, not compute starvation, so pair this with [CPU](/sensors/server-resources/cpu-utilization.md) and disk metrics before drawing conclusions.

## Alerting on this metric externally

Polling `laLoad` tells you the run queue is deep right now. What averts an incident is being told the moment it's been deep too long — and a heavily loaded server is precisely the machine least able to send that message. When load is high because the CPUs are pegged or the box is stuck in I/O wait, a local alerting agent competes for the same starved resources. It may never get scheduled to fire.

Watching from outside removes the dependency entirely. That's the reasoning behind [double durability](/monitoring/double-durability.md): an independent poller keeps reading `1.3.6.1.4.1.2021.10.1.3` on its own hardware and schedule, so an overloaded — or crashed — server still trips its threshold. SNMP is a pull protocol, so the external checker just asks; the struggling host doesn't have to spare cycles to report on itself.

![Chart of the SNMP 1, 5 and 15-minute load averages over 24 hours with an alert threshold line](https://snmp-monitoring.com/img/sensors/snmp-load-average-chart.webp)


## FAQ

**What's the difference between SNMP load average and CPU utilization?**
Load average (`laLoad`, `1.3.6.1.4.1.2021.10.1.3`) counts processes running or waiting, including I/O wait, and isn't capped at 100. CPU utilization (`hrProcessorLoad`, `1.3.6.1.2.1.25.3.3.1.2`) is a 0–100 percentage of processor time per core. Load can be high while CPU looks idle — that's I/O wait.

**Which of the three load figures should I alert on?**
Use the 5- or 15-minute average (`laLoad.2` or `laLoad.3`) for alerting, since they smooth out brief spikes. The 1-minute figure (`laLoad.1`) is best for spotting whether load is currently rising or falling.

**Is `laLoad` a standard, RFC-defined OID?**
No. It lives in the UCD-SNMP-MIB under the Net-SNMP enterprise branch `1.3.6.1.4.1.2021`, which is a vendor MIB, not an IETF standard. It's available wherever Net-SNMP runs.

**How do I interpret the raw number?**
Divide it by the server's core count. Below 1.0 per core there's headroom; around 1.0 the machine is fully used; well above 1.0 and sustained, work is backing up.

## Conclusion

SNMP system load monitoring rests on one small vendor table — `laLoad` at `1.3.6.1.4.1.2021.10.1.3`, with `.1`, `.2`, and `.3` giving the 1-, 5-, and 15-minute averages — always read per core and, for alerting, on the longer windows. Remember it isn't a percentage and isn't the same as CPU. Publish it in your [snmpd.conf](/setup/snmpd-conf.md), keep it in your [OID allowlist](/setup/oid-allowlist.md), and find its siblings in the [sensor & OID catalog](/sensors/index.md) and [complete OID list](/sensors/all.md). Monitor snmp load average from outside your network with [ostr.io Monitoring](https://ostr.io/service/monitoring), so an overloaded server still reaches you by email and SMS.