---
type: Article
title: "Set Up Low-Disk-Space Alerts"
description: "Get warned at 80% full, not 100%: the SNMP storage OIDs, the math to turn allocation units into gigabytes, and how to alert from outside the server."
resource: "https://snmp-monitoring.com/guides/low-disk-space-alerts/"
tags: [guides, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Diagram of an external SNMP poller reading hrStorageSize and hrStorageUsed from a server to compute a percent-full low disk space alert](https://snmp-monitoring.com/img/guides/low-disk-space-alert.webp)

## 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](/setup/oid-allowlist.md) shows the `view` syntax; the [snmpd.conf setup](/setup/snmpd-conf.md) 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:
   ```bash
   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:
   ```bash
   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).

| Column | OID | Object | Meaning |
|---|---|---|---|
| Description | `1.3.6.1.2.1.25.2.3.1.3` | hrStorageDescr | Volume / RAM / swap label |
| Allocation unit | `1.3.6.1.2.1.25.2.3.1.4` | hrStorageAllocationUnits | Bytes per unit (multiply to get bytes) |
| Size | `1.3.6.1.2.1.25.2.3.1.5` | hrStorageSize | Total, in allocation units |
| Used | `1.3.6.1.2.1.25.2.3.1.6` | hrStorageUsed | Used, in allocation units |

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:

```bash
# 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](/monitoring/double-durability.md): 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](https://ostr.io/service/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.

![Bar chart of multiple server volumes by percent full with warning and critical threshold lines for a disk full notification](https://snmp-monitoring.com/img/guides/disk-usage-thresholds.webp)


## FAQ

**Which OIDs give disk usage for a low disk space alert?**
The Host Resources storage table: `hrStorageSize` (`1.3.6.1.2.1.25.2.3.1.5`) and `hrStorageUsed` (`1.3.6.1.2.1.25.2.3.1.6`), labelled by `hrStorageDescr` (`1.3.6.1.2.1.25.2.3.1.3`). Percent full is used divided by size, times 100.

**Why are the numbers not in bytes?**
The table reports in *allocation units*. `hrStorageAllocationUnits` (`1.3.6.1.2.1.25.2.3.1.4`) tells you the bytes per unit — multiply to get real capacity. For a percentage you can ignore it, because the units cancel in the ratio.

**What threshold should I alert at?**
As qualitative guidance, warn around 80% full and treat roughly 90% as critical, so you have time to act before the partition is truly out of room. Tune per host — some volumes normally run hot, and a flat threshold pages you needlessly.

**Does the storage table cover RAM and swap too?**
Yes. `hrStorageDescr` labels every storage area the host reports, which includes physical memory and swap alongside mounted disks. Filter by the description to alert only on the volumes you care about.

## Conclusion

Setting up low disk space alerts over SNMP comes down to three columns of one table: `hrStorageDescr` to name the volume, `hrStorageSize` and `hrStorageUsed` to compute percent full. Warn around 80%, page around 90%, poll every few minutes, and — crucially — poll from outside the server so a full disk can't gag its own disk full notification. Read the table, do the division, and you'll hear about the partition while there's still time to save it, not after it's already broken everything downstream. For related use-cases, browse the full [SNMP monitoring guides](/guides/index.md) or return to the [knowledge base home](/index.md).