---
type: Article
title: "SNMP Traps vs Polling: When to Use Each"
description: "Polling means the manager asks on a schedule; a trap means the agent speaks first when something happens. Opposite directions — and when to reach for each."
resource: "https://snmp-monitoring.com/what-is-snmp/traps-vs-polling/"
tags: [what-is-snmp, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Traps vs Polling

The SNMP trap vs poll question is really a question about who starts the conversation. With polling, your manager asks the agent for a value on a schedule — over and over, on your clock. With a trap, the agent speaks first, firing an unsolicited message the instant something noteworthy happens. Same protocol, opposite direction. Both have their place, and picking wrong leaves you either drowning in traffic or blind to the very event you cared about. This page pins down snmp polling vs traps so you know which to reach for.

## What is Traps vs Polling — definition

Polling is a **pull** model. The manager sends a GET or GETBULK request, the agent answers, and the manager stores the result. Nothing happens on the agent's side until you ask. You control the cadence, the timing, the whole rhythm.

A trap is a **push** model. The agent detects a condition — an interface going down, a reboot, a threshold crossed — and immediately sends an SNMP trap to a manager without being asked. Traps are one-way and fire-and-forget: the agent sends and moves on, with no acknowledgement in the classic form.

So the core distinction in snmp trap vs poll is initiative. Polling is the manager checking in at intervals. A trap is the device raising its hand. One gives you a steady stream of measurements you can graph; the other gives you a fast, event-driven heads-up. Most real monitoring setups use both — poll for the trend line, trap for the emergency.

It helps to think about *what each one is good at knowing*. Polling answers "how much?" — how full is the disk, how hard is the CPU working, how much traffic crossed the link. Those are continuous quantities, and you want them sampled regularly to draw a curve. A trap answers "did something just happen?" — a link dropped, a power supply failed, a fan stopped. Those are discrete events with a precise moment, and sampling is a clumsy way to catch a moment. Match the tool to the shape of the question and the whole debate gets simpler.

![Diagram contrasting SNMP polling, where a manager pulls values from an agent on UDP 161, with an SNMP trap the agent pushes to a receiver on UDP 162](https://snmp-monitoring.com/img/what-is-snmp/trap-vs-poll-flow.webp)

## How it works

Polling rides on the standard request operations. The manager sends a GET for a scalar, a GETNEXT to step through a table, or a GETBULK to grab many rows at once, and the agent replies on UDP port 161. You decide the interval — every 30 seconds, every 5 minutes — and that interval is the resolution of everything you'll ever see. Poll uptime (`1.3.6.1.2.1.25.1.1.0`) once a minute and you can't detect a blip that started and ended in the intervening 59 seconds. That's the fundamental limit of pulling: you only know what the world looked like at each sample.

Traps flow the other way, to UDP port 162 on the receiver. The agent is configured with a trap destination and a set of conditions; when one trips, it composes a notification and sends it. Because traps travel over UDP with no built-in retransmission, a trap lost to a dropped packet or a busy network is simply *gone* — you never learn it happened. That single fact shapes when you can trust them.

A practical way to decide between them, metric by metric:

1. Is the thing you're watching a continuous quantity (CPU, disk, throughput)? Poll it.
2. Is it a discrete event with an exact moment (link down, reboot, power fail)? Trap it.
3. Does a missed signal cause real harm? Back the trap with a poll, or use an acknowledged inform.
4. Is the host likely to be dead when it matters? Rely on an outside poll — a corpse can't send a trap.

Here's the asymmetry that decides most designs. Polling detects *presence* — the agent answered, so it's alive — and it detects gradual change well. But it can't catch a fast transient between samples, and it costs traffic on every cycle. Traps detect *events* the moment they occur and cost nothing until something happens, but they're unreliable in transit and can flood you during a storm (one flapping link can emit hundreds). Neither wins outright. You poll for the metrics that populate your dashboards — CPU, memory, throughput — and you trap for discrete alarms you can't afford to sample your way into missing.

## Key components / concepts

| Aspect | Polling (pull) | Traps (push) |
|---|---|---|
| Initiator | Manager | Agent |
| Direction | Manager → agent → reply | Agent → manager, one-way |
| Default port | UDP 161 | UDP 162 |
| Operations | GET, GETNEXT, GETBULK | TRAP / SNMPv2-Trap notification |
| Timing | Fixed interval you set | Immediate, event-driven |
| Reliability | Retries under your control | Fire-and-forget over UDP; can be lost |
| Best for | Trends, graphs, presence checks | Sudden discrete events, alarms |
| Weakness | Misses fast transients; steady traffic | Lost packets vanish; trap storms |

One clarification people ask for: an *inform* is an acknowledged variant of a notification introduced in SNMPv2c — the receiver confirms it got the message, so it's more reliable than a raw trap at the cost of extra round-trips. The plain snmp trap remains unacknowledged.

There's also a cost dimension that tends to decide large deployments. Polling scales with the number of devices *times* the number of OIDs *times* the polling rate — a thousand devices polled tightly for a dozen metrics each is a lot of steady query traffic, all of it flowing whether anything is wrong or not. Traps invert that: they cost nothing while things are healthy and only generate traffic on an event. The catch is that "an event" during a real incident can mean thousands of traps in seconds, so the quiet-until-it-isn't profile of traps is a blessing right up until the storm. Neither model is free; they just bill you at different times.

## Practical example

Polling is something you can run by hand right now. Walk an interface table to watch link state, using the [IF-MIB](/sensors/network/interface-traffic.md) `ifOperStatus` column:

```bash
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.2.2.1.8
```

```
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: down(2)
```

Run that on a timer and you're polling. To catch the moment `ifOperStatus.2` flips from `up(1)` to `down(2)`, a trap-based agent would instead push a `linkDown` notification to your receiver on port 162 the instant it happened — no waiting for the next poll cycle. The trade is visible in the example itself: the walk you can repeat and trust; the trap arrives faster but only if the packet survives the trip. That's snmp polling vs traps in one screen.

## Common pitfalls / notes

- **Relying on traps for critical state.** A lost trap is silent. Back every important trap with a poll so a missed packet doesn't become a missed outage.
- **Polling too aggressively.** A tight interval multiplies traffic across every device and every OID. Match cadence to how fast the metric actually changes.
- **Ignoring trap storms.** One flapping interface can emit a flood. Rate-limit or dampen at the receiver.
- **Forgetting the port split.** Polling is UDP 161, traps land on UDP 162. A firewall that allows one but not the other silently breaks the half you forgot.
- **Trusting a trap you can't verify.** If it matters, use an inform (acknowledged) or confirm with a poll.

A note on external monitoring: ostr.io's SNMP Health Monitoring is **poll-based over SNMPv2c**. It queries your server's OIDs on a schedule from outside your network, which sidesteps the biggest weakness of traps — a crashing host often can't send its own trap, but an outside poller notices the silence anyway. Configure the v2c agent it polls in the [setup guide](/setup/snmpd-conf.md).

![Timeline illustration showing scheduled poll samples missing a brief spike while an SNMP trap fires the instant the event occurs](https://snmp-monitoring.com/img/what-is-snmp/snmp-polling-vs-traps-timeline.webp)

## FAQ

**What's the main difference between an SNMP trap and polling?**
Direction and initiative. Polling is the manager pulling values from the agent on a schedule; a trap is the agent pushing an unsolicited message the moment an event occurs. Polling suits trends and presence; traps suit sudden alarms.

**Are SNMP traps reliable?**
Not inherently. A standard trap is fire-and-forget over UDP with no acknowledgement, so a dropped packet is lost for good. Use informs (acknowledged notifications) or confirm critical traps with a poll when reliability matters.

**Which ports do traps and polling use?**
Polling requests go to UDP port 161 on the agent. Traps and notifications go to UDP port 162 on the receiver. They're separate paths, so firewall rules must allow both if you use both.

**Should I use polling or traps for server monitoring?**
For server health you'll mostly poll — CPU, memory, and disk are trends you want graphed, and polling from outside also catches a host that has gone completely silent. Add traps for discrete events you can't afford to sample your way past.

## Conclusion

The snmp trap vs poll decision comes down to who initiates and what you're watching. Polling is the manager pulling metrics on your schedule — reliable, graphable, but blind between samples and quiet during a full outage unless someone's checking from outside. A trap is the agent pushing an event instantly — fast, but fire-and-forget over UDP and prone to storms. Use polling for trends and presence, traps for discrete alarms, and lean on both. Because a downed server can't send its own trap, external polling is what closes the gap; that's the [double durability](/monitoring/double-durability.md) idea, implemented by [ostr.io Monitoring](https://ostr.io/service/monitoring). See also the three [SNMP versions](/what-is-snmp/snmp-versions.md).