SNMP Uptime & Reboot Detection

SNMP uptime is the quiet metric that catches the outages you'd otherwise only hear about from users. It's a running counter of how long a host has been up — and the instant that counter drops back toward zero, you know the machine rebooted. That's the whole trick to reboot detection over SNMP: you don't need a special "was there a reboot?" signal, you just watch a number that only ever climbs, and treat any reset as an event. This guide covers what the uptime value means, the exact host uptime OID that reports it, how to read it, how to turn it into reliable reboot alerts, and why an outside observer is the only one that can tell you the box went down and came back.

What is Uptime & Reboot Detection and why monitor it

Uptime is elapsed time since the system last started. It climbs steadily, second after second, for as long as the host stays up. A reboot — planned or not — resets it to zero, and it begins climbing again. That simple, monotonic behaviour is what makes it so useful: the value itself is mildly interesting, but the reset is the real signal.

Why does that matter operationally? Because an unexpected reboot is rarely benign. It can mean a kernel panic, a power event, a hardware fault, an OOM-triggered restart, or someone running reboot without telling anyone. Worse, a server can crash and recover so quickly that every dashboard looks green again by the time you glance at it — the outage is invisible unless something noticed the uptime reset. Monitoring SNMP uptime turns those silent bounces into a recorded, alertable event.

There's a second, sneakier failure mode: the reboot loop. A machine that panics, restarts, runs for ninety seconds, and panics again will show an uptime that keeps resetting to a small value. Watch the counter over time and that sawtooth pattern is unmistakable — and it's the kind of thing you want to catch at 3 a.m., not discover in the morning. The symptoms your users report (dropped connections, lost sessions, brief 5xx bursts) all trace back to a counter you could have been watching.

The OID: 1.3.6.1.2.1.25.1.1.0

The host uptime OID is 1.3.6.1.2.1.25.1.1.0, named hrSystemUptime in the Host Resources MIB (RFC 2790). It's a scalar — a single leaf, not a table — which is why it ends in .0. The value type is TimeTicks: hundredths of a second since the host started, so 100 ticks is one second and the number gets large quickly.

One clarification worth making, because it trips people up. There are two "uptime" OIDs floating around. sysUpTime (in MIB-II) measures how long the SNMP agent has been running, which can reset when you restart the daemon even though the machine never rebooted. hrSystemUptime at 1.3.6.1.2.1.25.1.1.0 measures how long the host has been up — that's the one you want for genuine reboot detection. Reading TimeTicks by hand is easy enough: divide by 100 for seconds, then by 8,640,000 for days. Most tools render it as a human-friendly duration for you.

How to query it

Any Net-SNMP client reads it in one call. These assume an SNMPv2c agent with a read-only community; if that's not set up, the snmpd.conf guide covers it.

1. Get the current uptime:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.1.0
   

   HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (109876543) 12 days, 17:12:45.43
   

   Net-SNMP prints both the raw ticks and a parsed duration — handy for a human, but your monitoring stores the raw ticks so it can compare between polls.
2. Force numeric output if the MIB isn't installed locally:

   snmpget -v2c -c public -On 10.0.0.5 1.3.6.1.2.1.25.1.1.0
   

3. Detect a reboot by comparing polls. In pseudo-terms: if this poll's ticks are lower than the previous poll's, the host rebooted in between. That single comparison is the entire reboot-detection rule.

The clean way to alert is to store the last value and flag any decrease. No decrease over time is a healthy, steadily rising counter; a decrease is a reboot event you should record and notify on.

Normal vs alarming values & thresholds

Uptime is unusual — you don't alert on the number being high or low, you alert on how it changes:

• Steadily increasing — normal and healthy. The host has stayed up since the last known start.
• A single reset to near-zero — a reboot happened. Whether that's alarming depends entirely on whether you scheduled it.
• Repeated resets in a short span — a reboot loop. Critical; the machine can't stay up, and this needs immediate attention.
• Unexpectedly low uptime on a server that should have been up for weeks — investigate; something restarted it without your knowledge.
• A poll that returns nothing at all — not an uptime story but an availability one: the host or its agent is unreachable, which may itself be the outage.

A word on "very high is good, very low is bad" — resist it. Enormous uptime isn't automatically healthy; a box that hasn't rebooted in two years is also a box that hasn't applied a kernel security patch in two years. The signal you actually want is the unexpected reset, not a leaderboard for the longest streak.

Alerting on this metric externally

Here's the catch that makes reboot detection different from every other metric on this site: a reboot is, by definition, a window where the server isn't running. The host can't tell you it went down, because while it was down there was nothing there to send the message. Any alerting agent living on that machine went down with it — and when the box comes back, the agent starts fresh with no memory that anything happened.

An outside observer has none of those blind spots. That's the essence of double durability: an independent watcher polls 1.3.6.1.2.1.25.1.1.0 from beyond your network, remembers the previous value across the outage, and sees the counter reset even though the host itself has no idea it was ever gone. It also notices the gap — the polls that timed out while the machine was rebooting. SNMP's pull model is exactly right here: the external side keeps asking, and it's the one holding the before-and-after that proves a reboot occurred.