monitoring

SNMP Host Availability Monitoring (Up/Down Detection)

Use SNMP Gets and uptime with ICMP and service checks for honest availability.

By the SNMP Monitoring team · Reviewed July 2026

“Is it up?” sounds binary until production humbles you. The host might ping while snmpd is dead. snmpd might answer while the app is wedged. A reboot might look like a blip. SNMP availability is one layer: agent responds, maybe uptime moved. It is not the whole stack.

Parent: monitoring. Uptime deep dive: server uptime. Wire path: how it works.

What "available" means

Bulleted layers people confuse:

  • IP reachable — ICMP/ARP works
  • Agent responding — Get/Response on UDP 161 succeeds
  • OS uptime climbing — host not stuck in reboot loop
  • Service working — TCP/HTTP/app check succeeds

SNMP cleanly covers the agent layer and helps with reboot detection. It does not prove checkout works.

Using the agent's response as a signal

A successful GetRequest → Response proves:

  • Something is listening on the path to UDP 161
  • Credentials/view allowed that OID
  • Agent process is alive enough to answer

A timeout means: host unreachable, agent down, ACL/firewall, wrong community/user, or wrong address—not “metric is zero.”

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (120000) 0:20:00.00

Success → agent path OK. Timeout → start troubleshooting, don’t invent data.

Layers of availability: reachable, agent responding, service working

Uptime & reboot detection

sysUpTime 1.3.6.1.2.1.1.3.0 going backwards (large drop) signals agent/host restart depending on which uptime you track. Prefer hrSystemUptime for host boot—see uptime how-to.

Availability check: “did the Get succeed?”
Reboot check: “did uptime reset?”
Different alerts. Don’t merge them into one vague “down.”

SNMP's blind spots

Signal What it proves What it does not prove
ICMP OK IP stack answers ping Agent or app up
SNMP Get OK Agent + SNMP path OK App/business logic OK
Uptime high Long since boot/agent init Service healthy
HTTP 200 Service responds Backend DB healthy (maybe)

A live agent with a dead application is a classic false green if you only watch SNMP.

External availability checks

When the failure domain includes your on-prem poller, add off-box checks. External SNMPv2c polls still need the agent, but they don’t share the rack’s fate. ostr.io style double durability (frequent + infrequent polls) is one pattern for external availability—see external monitoring, setup.

One contextual CTA; combine with your own ICMP/HTTP regardless of vendor.

Combining signals

Numbered approach that works:

  1. ICMP (or TCP ping) — crude reachability
  2. SNMP Get of sysUpTime or a cheap scalar — agent alive
  3. Service check — port/HTTP/synthetic
  4. Uptime logic — reboot vs hang
  5. Correlate — page on combinations (ICMP fail + SNMP fail = host/network; ICMP OK + SNMP fail = agent/ACL; both OK + HTTP fail = app)

Worked polling logic (pseudo)

Every minute: snmpget sysUpTime.

  • OK → mark agent up; compare uptime for reboot.
  • Timeout → mark agent down; if ICMP also down → host/network; if ICMP up → agent/firewall/creds.
    Never write zeros into graphs on timeout—mark missing.

Ops checklist

  1. Separate alerts: agent down vs reboot vs app down
  2. Use real poller source IPs in tests
  3. Document maintenance that restarts snmpd
  4. Add external check for crown-jewel hosts
  5. Review false greens quarterly

Failure modes

  • Timeout graphed as 0 uptime
  • “Host down” when only community wrong
  • Trusting SNMP alone for SLA
  • No external path

Glossary: glossary.

State machine you can implement

Define host states explicitly in the NMS:

  1. OK — SNMP Get succeeds
  2. AGENT_DOWN — SNMP fails, ICMP OK
  3. HOST_UNREACHABLE — SNMP fails, ICMP fails
  4. REBOOTED — SNMP OK, uptime reset detected
  5. DEGRADED — SNMP OK, app check fails

Page differently for 2–5. If everything collapses into “DOWN,” you will SSH into boxes that only need systemctl start snmpd and ignore app failures that need a rollback.

Credential failures look like downtime

Wrong community or v3 user produces timeouts or auth errors depending on agent. Before declaring an outage, validate credentials from the poller host with verbose snmpget. Rotate secrets with dual-write windows so you don’t create a fleet-wide “outage” that is really a config push bug.

Partial paths and management VRFs

Polling the wrong VRF/interface is a classic: production data plane up, management ACL blocks 161, availability red forever. Document the management address per device. External pollers need the path you actually opened in the firewall—not the address on the sticker.

Synthetic plus SNMP

For user-facing services, synthetic checks own the SLA story. SNMP owns “is the OS management plane answering?” Together they explain the difference between “AWS region issue,” “our rack lost power,” and “tomcat wedged.” Don’t pick one religion.

SLA honesty

If the contract is “API available,” measure the API. If the contract is “server ICMP up,” measure ICMP. SNMP agent uptime is a fine internal SLO for the management plane—not a substitute for customer SLIs. Put SNMP availability on the infra dashboard; put synthetics on the product dashboard; cross-link during incidents.

Flapping and backoff

When a host flaps, exponential backoff on pages and a single incident object beat 40 SMS. SNMP timeouts during congestion can flap too—require 2–3 failures before AGENT_DOWN, and clear only after 2–3 successes. Same hysteresis idea as metric alerts (alerts).

Checklist for a new host in monitoring

  1. ICMP green from poller
  2. snmpget sysUpTime green
  3. App check green
  4. Uptime series recording
  5. External check optional for tier-1

Skip 2 and you’ll discover snmpd disabled six months later when you need CPU history that was never collected.

When SNMP is the only tool you have

Small shops without synthetics still benefit from agent response + uptime + a TCP check to the main port. Three signals, three different failures. It’s not fancy. It works.

Dependency map

Draw arrows: user → LB → app → DB → storage. SNMP sits on each box, not on the arrow. An outage on the arrow (network ACL) can show all SNMP green from an internal poller and red from external—or the reverse. Always ask “from where is it unavailable?” Availability without vantage point is incomplete.

Store poller location in the alert: AGENT_DOWN from poller-dc1. That string alone prevents a wrong datacenter truck roll.

Frequently asked questions

Can SNMP tell me if a host is down?

It can tell you if the agent path fails. Host may still be up with snmpd stopped. Combine with ICMP and service checks.

Why does my SNMP check time out?

Unreachable host, dead agent, firewall/ACL, wrong credentials, wrong port/address. See troubleshooting.

Does a live agent mean the app works?

No. Agent health ≠ application health.

SNMP vs ping for availability?

Ping = IP reachability. SNMP = management agent. Use both, plus app checks.

Key takeaways

  • Availability is layered; SNMP covers agent response.
  • Success Get ≠ app OK; timeout ≠ always “host dead.”
  • Uptime drops help reboot detection.
  • Combine ICMP + SNMP + service; consider external durability.
  • CTA pattern: ostr.io for off-box polls.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.