By the SNMP Monitoring team · Reviewed July 2026
Polling interval is a trade-off: finer resolution and faster alerts versus load on the agent, network, and poller. There is no universal “every 30 seconds” religion. There is “fast enough for the metric, slow enough not to melt snmpd.”
Parent: monitoring. Traps for events: traps vs polling. GetBulk: PDU.
What polling frequency affects
- Data resolution — gaps between samples
- Alert latency — worst case ≈ interval × samples required
- Agent CPU/locks — especially big walks
- Network chatter — UDP 161 storms
- Poller capacity — schedule backlog
Bulleted truth: faster is not free. Slower is not always safer (counter wrap, late pages).
Fast vs slow metrics
| Metric class | Suggested ballpark | Why |
|---|---|---|
| Interface counters / errors | 1–5 min (often near high end if 64-bit) | Rates; wrap risk on 32-bit |
| CPU / load / sessions | 1–5 min | Live ops signal |
| Disk free % | 5–15 min | Slow-moving until cliff |
| Temperature | 5–15 min | Thermal inertia |
| Inventory / static descr | 1–4×/day | Rarely changes |
Practice from the brief: high-frequency under 5 minutes for live metrics; low-frequency 1–4×/day for slow inventory/capacity snapshots.
The counter-wrap constraint
32-bit counters on busy links wrap. Your poll interval must be shorter than wrap time or rates go nonsense. Prefer 64-bit IF-MIB counters (ifHC*) when available to relax the constraint. If you’re stuck on 32-bit, poll faster or accept garbage rates at peak.
Test with a known busy interface; if rates go negative/absurd, you wrapped or mis-handled reset.
The dual-endpoint pattern
One poller definition at 60s for everything is crude. Better:
Numbered dual cadence:
- Frequent endpoint/check — critical live metrics, interval under 5 minutes
- Infrequent endpoint/check — wider OID set, 1–4×/day
- Stagger schedules so top-of-minute stampedes don’t hit all hosts
- Keep allowlists tight on both
ostr.io documents this as double durability: two endpoints, high- and low-frequency, for visibility without one overloaded path. DIY NMS can clone the idea with two templates. External: external, setup: ostr.io.
Avoiding agent overload
- Prefer GetBulk for tables (PDU)
- Don’t walk entire mib-2 every minute
- Batch OIDs sensibly
- Stagger host schedules
- Separate “discovery” walks from steady-state polls
- Watch snmpd CPU when you change intervals
Worked schedule example
- Every 2 min: sysUpTime, CPU, load, RAM %, root disk %, critical process presence
- Every 5 min: interface HC counters for uplinks
- Every 15 min: other disks, temperature
- 2×/day: full interface inventory, software descr
Tune after measuring poller runtime and agent CPU.
Prove the interval
snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (60000) 0:10:00.00
If a single Get is slow, your 10-second full walk fantasy is dead on arrival.
Failure modes
- Global 30s polls for vanity dashboards
- 30-min polls on 32-bit counters
- Discovery walk every cycle
- No dual cadence → either blind or overloaded
Glossary: glossary.
Capacity planning for the poller
Estimate: hosts × checks × (1/interval) ≈ polls per second. Add walk weight. If the poller queue latency grows, you don’t have monitoring—you have delayed fiction. Scale horizontally (shard by site) before you cut every interval to 10 seconds “because Grafana looks cooler.”
Aligning intervals with alert duration
If you require 3 failed samples and poll every 5 minutes, worst-case detect time is ~15 minutes before the alert even arms. Product owners who want 1-minute MTTD need 1-minute polls and fewer samples—or traps for events. Write the math on the whiteboard when someone demands both “gentle polling” and “instant pages.”
Stagger patterns
Don’t schedule 500 hosts at second 0 of every minute. Jitter start times across the interval. Agents and firewall session tables thank you. Same for dual endpoints: don’t align frequent and infrequent peaks.
When to slow down
- Agent CPU high during polls
- Poller backlog
- Network congested management plane
- You’re walking tables you graph as scalars
Slow the heavy checks first, not the sysUpTime heartbeat.
When to speed up
- 32-bit counters misbehaving
- SLA needs faster detection
- Flapping issues you currently miss between 15-min samples
Speed specific checks, not the entire template pack.
Dual durability without a SaaS
Two NMS templates, two intervals, same allowlist philosophy. Or primary NMS + secondary external. The name “double durability” is product language for a pattern you can implement with open tools—just don’t forget the infrequent side only helps if someone still looks at it or alerts on it.
Sample policy you can paste into a design doc
- Heartbeat scalars (sysUpTime, agent check): 1–2 min
- Host resources (CPU, load, RAM, sessions): 2–5 min
- Disk free: 5–10 min
- Uplink HC counters: 2–5 min (faster if still on 32-bit)
- Full interface table discovery: daily
- Hardware temps: 10–15 min
- External dual checks: frequent <5 min, infrequent 1–4×/day
Revise after measuring. Policy without measurement is cosplay.
GetBulk and timeout tuning
Faster polls with fat GetBulks time out and retry—effectively slower and meaner. Cap max-repetitions, split tables, and watch timeout/retry settings on the manager. A clean 5-minute poll beats a broken 30-second poll that never completes.
Business hours vs 24/7
Some non-prod can poll slower nights and weekends. Prod rarely can. If you change intervals by calendar, document it so nobody “optimizes” prod the same way.
Review cadence
When onboarding a new metric, ask: what decision does a sample enable, and how late can that decision be? That answer is the interval. If nobody can name the decision, don’t poll it every minute—or don’t poll it at all.
Interaction with traps
Faster polling does not replace traps for discrete faults. You can poll interfaces every minute and still want linkDown traps for sub-minute detection. Conversely, traps without any polling leave you blind when the agent dies quietly. Budget interval for metrics; keep traps for events (traps vs polling).
One-page summary for managers
“We poll critical host metrics every few minutes, inventory daily, use 64-bit counters so we needn’t hammer the network, and dual-cadence external checks for crown jewels.” That sentence is the strategy. Everything else is implementation detail for the NMS ticket.
Frequently asked questions
How often should I poll SNMP?
Depends on the metric. Live signals often under 5 minutes; inventory 1–4×/day. See the table.
What is a good SNMP polling interval?
Start 2–5 minutes for core host metrics; adjust for counter wrap and agent load.
Why two polling endpoints?
Frequent + infrequent splits critical resolution from heavy/rare data—double durability / dual cadence.
How does polling rate relate to counter wrap?
Interval must be shorter than time-to-wrap for 32-bit counters; use 64-bit counters when you can.
Key takeaways
- Interval = resolution vs load.
- Fast for live; slow for inventory.
- Respect counter wrap; prefer 64-bit.
- Dual cadence reduces overload.
- GetBulk + stagger; optional ostr.io dual endpoints.