Set Up Low-Disk-Space Alerts

A good low disk space alert warns you at 80% full, not at the 100% where everything's already on fire. SNMP makes that easy: the server publishes each volume's size and usage through a standard storage table, you divide one by the other, and you get a percent-full number you can put a threshold on. This guide walks the exact OIDs, the math to turn allocation units into real gigabytes, and how to fire a disk full notification from outside the server — so a wedged host still reaches you.

The problem

A full disk is one of the most boring outages there is, and one of the most destructive. The failures cascade in ways that rarely point back to storage:

• Databases refuse writes and may corrupt on the way down.
• Logs stop rotating, then stop being written at all — so you lose the very record that would explain the mess.
• Package managers choke, sessions won't save, and half your services throw errors that look like anything except a full disk.

The root cause is dull; the blast radius is enormous. And you often diagnose it last, precisely because the symptoms wear so many disguises.

Worse, disks don't fill on a schedule you can predict. A runaway log, a debug flag left on, an upload nobody capped, a backup job that forgot to prune — any of them can eat a partition in hours. You were fine at bedtime and out of space by breakfast.

The instinct is to SSH in and run df -h. Fine for a spot check; useless as a strategy. Nobody runs df every ten minutes across every server, and the one time you needed to, you were asleep. What you actually want is a standing low disk space alert that watches every volume continuously and pokes you well before the partition hits the wall — while there's still room to fix it.

Solution overview

SNMP has a purpose-built answer: the storage table in the Host Resources MIB (RFC 2790). Every disk, RAM area, and swap space the host knows about shows up as a row, and each row carries a name, a total size, and an amount used. Read three columns and the percentage falls right out.

The columns are hrStorageDescr (the label), hrStorageSize (total, in allocation units), and hrStorageUsed (used, in the same units). Percent full is simply used ÷ size × 100. There's one gotcha worth knowing upfront: those sizes aren't in bytes. They're in allocation units, and hrStorageAllocationUnits tells you how many bytes each one is — multiply if you want a human-readable capacity. For a pure percentage, you can skip that step entirely, since the units cancel.

Poll those OIDs on a cadence, compute the ratio per volume, and compare against a threshold. Warn early, page late. And do the polling from outside the machine, so a disk that's full enough to break the host's own alerting still triggers your disk full notification.

Step-by-step

Here's how to set up low disk space alerts from scratch.

1. Expose the storage table. Add the storage OIDs to your agent's allowlisted view in /etc/snmp/snmpd.conf, read-only over v2c. The OID allowlist guide shows the view syntax; the snmpd.conf setup covers community and access. Then service snmpd restart.
2. List your volumes. From the poller, render the whole table so you can see what's there and which index maps to which mount:

   snmptable -v2c -c public 203.0.113.10 1.3.6.1.2.1.25.2.3.1
   

3. Identify the volumes that matter. Match the hrStorageDescr labels to your real partitions — /, /var, a data mount. Note their row indexes. Ignore the read-only or throwaway ones if you like.
4. Read size and used per volume. For a given index N, pull the two numbers:

   snmpget -v2c -c public 203.0.113.10 1.3.6.1.2.1.25.2.3.1.5.N 1.3.6.1.2.1.25.2.3.1.6.N
   

5. Compute percent full. Divide used by size and multiply by 100. Because both are in the same allocation units, the units cancel and you get a clean percentage without touching hrStorageAllocationUnits.
6. Set two thresholds. A warning around 80% full gives you runway to act; a critical around 90% means intervene now. Poll every few minutes and alert per volume — a full /var and a full data disk are different fires.

That's the whole loop. Expose the table, map your volumes, compute the ratio, and alert on the threshold before the partition tops out.

Configuration / example

These are the storage-table OIDs a low disk space alert is built on, all from the Host Resources MIB (RFC 2790).

To turn units into real capacity, multiply by the allocation unit. If hrStorageSize is 26214400 and hrStorageAllocationUnits is 4096 bytes, total capacity is 26214400 × 4096 ≈ 107 GB. For alerting you rarely need that — the ratio is enough:

# Percent-full for storage row index N
size=$(snmpget -v2c -c public -Ovq 203.0.113.10 1.3.6.1.2.1.25.2.3.1.5.N)
used=$(snmpget -v2c -c public -Ovq 203.0.113.10 1.3.6.1.2.1.25.2.3.1.6.N)
echo "$(( used * 100 / size ))% full"

The -Ovq flags return the raw value only, so the arithmetic stays simple. Watch for the edge case where a partition legitimately sits at 95% — set that host's threshold accordingly instead of paging on every poll.

External alerting

A disk full notification is only useful if it escapes the server, and a nearly-full server is exactly the kind that struggles to send anything. Once a partition hits 100%, the local mailer may not be able to write its own spool file. The log the alert tool reads can't grow. Your on-host warning system needs disk to warn you about running out of disk — a nasty little circular dependency.

Polling the storage table from outside sidesteps all of it. The external checker reads hrStorageUsed and hrStorageSize over the network, does the division on its own hardware, and sends the alert from a machine with plenty of room. That's double durability: the watcher doesn't share the failure it's watching for, so a full or frozen disk still produces a signal.

Monitor low disk space alert from outside your network with ostr.io Monitoring. It polls your SNMP storage OIDs independently and fires real-time email and SMS alerts as a volume approaches full — reaching you even when the host is too jammed to send its own disk full notification.