SNMP Load Average OIDs: UCD laLoad Reference

By the SNMP Monitoring team · Reviewed July 2026

Load average isn't in MIB-II — there's no standard "load" object the way there's a standard interface counter. It lives in the UCD-SNMP-MIB, the Net-SNMP enterprise tree, as the laLoad table with the familiar 1/5/15-minute values. This page is the paste-ready reference: the string, integer, and float variants, the threshold config objects, and the one caveat that catches people — these OIDs only exist on Net-SNMP agents.

The "how do I alert on load without false pages" side is the twin: monitor system load. Hubs: sensors, all OIDs.

laLoad 1/5/15 OIDs

The load table sits at 1.3.6.1.4.1.2021.10.1, with three rows for the three time windows:

The base column is laLoad at 1.3.6.1.4.1.2021.10.1.3; the trailing .1 / .2 / .3 select 1, 5, and 15 minutes. Note the type is STRING — the value comes back as text like "0.42", which every NMS parses as a float, but it's worth knowing so you don't treat it as an integer.

Integer and float variants

Because a string is awkward for some tooling, UCD exposes the same numbers in two other forms:

• laLoadInt — 1.3.6.1.4.1.2021.10.1.5 — the load × 100 as an integer (so 0.42 becomes 42). Handy for systems that want an integer OID; divide by 100 to recover the real value.
• laLoadFloat — 1.3.6.1.4.1.2021.10.1.6 — the load as a true float (Opaque/Float), where the agent supports it.

When to use which: laLoadInt is the most portable if your poller dislikes string values — an integer scaled by 100 is unambiguous. laLoadFloat is cleanest where your stack handles floats natively. Plain laLoad (string) is the most universally present. Same three indexes (.1/.2/.3 = 1/5/15 min) apply to all three variants.

Load config OIDs

UCD also lets the agent carry its own alarm thresholds, which some setups poll instead of hard-coding limits in the NMS:

• laConfig — the configured load threshold for a row, set in snmpd.conf.
• laErrorFlag — a boolean the agent raises when the measured load exceeds its configured threshold.
• laErrMessage — a text description of the threshold breach.

These are convenient when you'd rather define the threshold once on the host (via the load directive in snmpd.conf) and let the agent flag breaches, though most monitoring systems prefer to own thresholds centrally. Either way the raw laLoad values are what you graph.

Worked snmpwalk example

Walk the load column for all three intervals:

snmpwalk -v2c -c <RO_string> <host> 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.61

Or grab the integer form (×100) if strings are inconvenient:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.4.1.2021.10.1.5.2

UCD-SNMP-MIB::laLoadInt.2 = INTEGER: 55

That 55 is 5-minute load 0.55. <RO_string> is a placeholder — allowlist the 2021.10.1 prefix rather than the whole enterprise tree, and keep live communities out of committed scripts.

Interpreting load

Load average is roughly the number of processes runnable or in uninterruptible wait — so the number only means something relative to how many CPUs the box has. The rule of thumb:

1. Find the CPU core count (from CPU OIDs or the platform).
2. Compare the load figure to that count: load ≈ cores means the CPUs are just kept busy; load well above cores means work is queuing and waiting.
3. Read the trend across the three windows — 1-minute rising above 5- and 15-minute means load is climbing now; the reverse means a spike is subsiding.

So 0.55 on a 4-core box is nearly idle, while 0.55 on a single-core box is more than half its capacity committed. Load is not CPU percent — a box can show high load with modest CPU% when processes are blocked on I/O, which is exactly why it's a distinct signal worth polling alongside hrProcessorLoad.

How to monitor load (how-to)

Reference stops here. The alerting logic — load-vs-core thresholds, choosing 5- vs 15-minute for paging, separating CPU-bound from I/O-bound load — is the twin: monitor system load via SNMP. Related: CPU OIDs, Linux SNMP, the OID catalog, and glossary.

Frequently asked questions

What OID is load average in SNMP?

laLoad at 1.3.6.1.4.1.2021.10.1.3 from the UCD-SNMP-MIB, with instances .1, .2, .3 for the 1-, 5-, and 15-minute averages. The values come back as strings like "0.55". Integer (laLoadInt, ×100) and float (laLoadFloat) variants exist under the same table.

Is load average in MIB-II?

No. Load average isn't a standard MIB-II object — it lives in the UCD-SNMP-MIB (the Net-SNMP enterprise tree under 1.3.6.1.4.1.2021). So you'll find it on Linux/Unix hosts running Net-SNMP, but not on gear that only implements the standard MIBs.

What is laLoadInt?

laLoadInt (1.3.6.1.4.1.2021.10.1.5) is the load average expressed as an integer scaled by 100 — so a load of 0.55 appears as 55. It exists because a plain integer OID is easier for some pollers to handle than the string-typed laLoad; divide by 100 to get the real value.

How do I read the 5-minute load?

Use the .2 instance of the load column: laLoad.2 at 1.3.6.1.4.1.2021.10.1.3.2 for the string value, or laLoadInt.2 at 1.3.6.1.4.1.2021.10.1.5.2 for the ×100 integer. The .1 and .3 instances give you the 1- and 15-minute figures.

Key takeaways

• Load average = laLoad at 1.3.6.1.4.1.2021.10.1.3, instances .1/.2/.3 = 1/5/15 min.
• It's UCD-SNMP, not MIB-II — Net-SNMP agents only.
• Values are STRING ("0.55"); use laLoadInt (…10.1.5, ×100) or laLoadFloat (…10.1.6) if you prefer numbers.
• Load only means something relative to CPU core count — it's not CPU percent.
• Read the 1/5/15 trend to tell rising load from a subsiding spike.
• Procedure: system load how-to; catalog: sensors/all.