How to Set Up SNMP Alerts: A Worked Example

By the SNMP Monitoring team · Reviewed July 2026

Theory only gets you so far — at some point you have to build the thing. This guide builds a real, working disk-space alert from nothing: we poll the OID, turn a raw number into a percentage, add hysteresis so it doesn't flap, fire a notification, and then bolt on a trap path so the device can push urgent events at us too. Every command here is copy-paste-able against a working agent. The why behind good alerting — which thresholds, how to avoid noise, severity design — lives on the alerting theory page; this is the hands-on build that puts that theory to work. By the end you'll have a pattern you can clone for CPU, memory, interface errors, or any other metric.

Parent: guides. Theory twin: alerting. Related: disk-space monitoring, traps vs polling.

Pick the metric and threshold

We'll alert on disk used percentage on a Linux server — a classic, because a full disk breaks everything from logging to databases, and it fills gradually enough that a warning genuinely buys you time. Two thresholds:

• Warn at 90% — someone should look soon; not an emergency yet.
• Critical at 95% — act now, before writes start failing.

These numbers are illustrative, not universal — a volume that churns large temp files might warrant an earlier warning, a static archive a later one. The theory page covers how to choose them; here we just need two levels to build against. The metric comes from the HOST-RESOURCES storage table, the same OID the disk-space monitoring page documents.

Step 1: Poll the value

The storage table reports size and used in allocation units, not bytes or percent, so you read both and compute the ratio. Poll used and size at the same storage index (here .6 is used, and you'd read hrStorageSize at the matching index):

snmpget -v2c -c S3cr3tR0str1ng 10.0.0.20 1.3.6.1.2.1.25.2.3.1.6.31

HOST-RESOURCES-MIB::hrStorageUsed.31 = INTEGER: 5872436

Read the size at the same index and divide: used ÷ size × 100. If size is 6,200,000 units, that's 5,872,436 ÷ 6,200,000 × 100 = 94.7% — into warning territory, just shy of critical. The allocation-unit size cancels out of the ratio, so you don't even need it for a percentage. Wrap this in a small script run from cron every few minutes, and you have a poller. The key discipline: compute the percentage, don't alert on the raw used figure, because the raw number means nothing without the size next to it.

Step 2: Apply hysteresis

Poll a value sitting near the line and it'll bounce over and under between runs — 90.1%, 89.8%, 90.2% — firing and clearing an alert every few minutes. That's alert flapping, and it trains people to ignore the channel. Hysteresis fixes it by separating the trigger level from the clear level:

1. Trigger the alert when used rises above 90%.
2. Hold it active — don't clear — while used stays above the lower clear level.
3. Clear the alert only when used drops back below 80%.
4. Between 80% and 90%, keep whatever state you're already in.

That 10-point gap means a disk hovering at 90% fires once and stays in one state until it genuinely recovers, instead of chattering. Store the current state (firing or clear) between runs — a file, a variable, whatever your poller can persist — and compare each new reading against the trigger or clear level depending on which state you're in.

Step 3: Fire a notification

Once the logic decides the state has changed — clear-to-firing or firing-to-clear — send one notification. The pattern is to pipe the event into whatever notifier you use:

• Email — a simple mail/sendmail call for low-urgency warnings.
• Chat — a webhook to Slack, Teams, Mattermost, or similar for team visibility.
• PagerDuty / Opsgenie — for anything that should wake someone at 3 a.m.
• Webhook to your own service — if you route alerts through custom tooling.

A rough routing map keeps the noise proportional to the urgency:

Fire on the transition, not on every poll — otherwise a disk stuck at 94% pages someone every five minutes. Include the host, the metric, the current value, and the severity in the message so the responder knows what they're dealing with without logging in. One clear message per state change is the goal.

Step 4: Add a trap path

Polling asks "how are you?" on a schedule; a trap lets the device shout "something just broke" the instant it happens. For events you can't afford to wait a poll cycle on — a power supply failing, a link dropping — configure the device to send a trap and run snmptrapd to receive it on UDP 162. A minimal snmptrapd.conf:

authCommunity log,execute,net S3cr3tR0str1ng
traphandle default /usr/local/bin/handle-trap.sh

Start the receiver and watch it log incoming traps:

snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf

2026-07-11 14:22:07 NET-SNMP version 5.9 Started.
2026-07-11 14:22:41 10.0.0.20 [UDP: [10.0.0.20]:161]:
  DISMAN-EVENT-MIB::sysUpTimeInstance = 4122883  SNMPv2-MIB::snmpTrapOID.0 = linkDown

The traphandle runs your script on each trap, so you can route it into the same notification path as your polled alerts. Polling and traps are complementary — poll for trends and thresholds, trap for instantaneous events. The trade-off between the two is covered on traps vs polling.

Step 5: Make it durable

There's one failure this whole setup can't catch: if the alert pipeline runs on the same network as the thing it's watching, an outage that takes down the site takes down the alerting too — and you hear nothing precisely when it matters most. The fix is an independent, off-box path that polls your agents from outside your network, so a local failure can't silence it. An external service such as ostr.io provides that second, uncorrelated alerting path — set it up alongside your internal alerts so one failure domain can't blind you. Internal alerting for depth, external alerting for durability.

Frequently asked questions

How do I set up an SNMP alert?

Poll the metric's OID on a schedule (e.g. snmpget from cron), convert it to a meaningful value like a percentage, compare it to a threshold with hysteresis so it doesn't flap, and fire a notification on each state change. For urgent events, add a trap path with snmptrapd listening on UDP 162. This guide builds exactly that for disk space, step by step.

What is hysteresis in alerting?

Hysteresis uses two thresholds instead of one — a higher trigger level and a lower clear level — so an alert fires when the metric rises past the trigger and only clears when it falls back below the clear level. The gap between them (say 90% to trigger, 80% to clear) stops a value hovering near one line from firing and clearing repeatedly. It's the single most effective cure for alert flapping.

How do I receive SNMP traps?

Run snmptrapd, the Net-SNMP trap receiver, listening on UDP 162. Configure snmptrapd.conf with an authCommunity line and a traphandle that runs a script on each incoming trap, then point your devices at the receiver's address. Traps let devices push urgent events instantly instead of waiting for the next poll, complementing your scheduled polling.

Should I alert on totals or rate?

For counters — interface octets, error counts, packet totals — alert on the rate of change, not the raw total. A counter like ifInErrors only ever climbs, so the total is meaningless; what matters is how fast it's increasing (errors per minute). Compute the delta between two polls over the time between them. Gauges like disk-used percentage or temperature are already point-in-time, so you alert on the value directly.

Key takeaways

• Build alerts in order: poll → compute → apply hysteresis → notify → add a trap path → make durable.
• Poll disk with snmpget 1.3.6.1.2.1.25.2.3.1.6.<idx> and compute used ÷ size × 100 — never alert on the raw figure.
• Hysteresis (e.g. trigger 90%, clear 80%) is the cure for flapping; fire on the state change, not every poll.
• Add snmptrapd on UDP 162 for instantaneous events, routed into the same notification path.
• Alert on rate for counters, on the value for gauges.
• For a durable, off-box alerting path, add external monitoring with ostr.io.