---
type: Article
title: "SNMP Uptime & Reboot Detection"
description: "SNMP uptime is a counter that only climbs — when it resets, the host rebooted. The exact OID, how to catch silent reboots, and how to spot a reboot loop."
resource: "https://snmp-monitoring.com/sensors/server-resources/uptime-reboot/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Timeline chart of hrSystemUptime counting up then resetting to zero at a reboot event, watched by an external SNMP poller](https://snmp-monitoring.com/img/sensors/snmp-uptime-reboot-timeline.webp)

## 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.

| Property | Value |
|---|---|
| OID | `1.3.6.1.2.1.25.1.1.0` |
| Object name | `hrSystemUptime` |
| MIB / standard | Host Resources MIB (RFC 2790) |
| Type | `TimeTicks` (hundredths of a second) |
| Structure | Scalar (single value) |
| Reboot signal | Value resets toward zero |

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](/setup/snmpd-conf.md) covers it.

1. **Get the current uptime**:
   ```bash
   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:
   ```bash
   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](/monitoring/double-durability.md): 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.

![Diagram of an external monitor polling the host uptime OID across a reboot gap and firing an email and SMS alert](https://snmp-monitoring.com/img/sensors/snmp-uptime-external-alert.webp)


## FAQ

**Which OID gives server uptime over SNMP?**
`hrSystemUptime` at `1.3.6.1.2.1.25.1.1.0`, from the Host Resources MIB (RFC 2790). It returns `TimeTicks` — hundredths of a second since the host booted.

**What's the difference between `hrSystemUptime` and `sysUpTime`?**
`hrSystemUptime` (`1.3.6.1.2.1.25.1.1.0`) tracks how long the *host* has been running. `sysUpTime` tracks how long the *SNMP agent* has been running, so it can reset when you restart the daemon without a real reboot. Use `hrSystemUptime` for reboot detection.

**How do I detect a server reboot with SNMP?**
Poll the uptime OID on a schedule and store each value. If a new reading is lower than the previous one, the counter reset — the host rebooted in between. Alert on that decrease.

**Why can't the server just tell me it rebooted?**
While a machine is down it can't send anything, and an on-host agent restarts clean with no memory of the outage. Only an external monitor that polls across the gap and remembers the prior value can prove the reboot happened.

## Conclusion

SNMP uptime monitoring turns one steadily climbing counter — `hrSystemUptime` at `1.3.6.1.2.1.25.1.1.0` — into reliable reboot detection: store each reading, and treat any drop as an event. Mind the difference from `sysUpTime`, publish the OID in your [snmpd.conf](/setup/snmpd-conf.md), keep it in your [OID allowlist](/setup/oid-allowlist.md), and browse its siblings in the [sensor & OID catalog](/sensors/index.md) and [complete OID list](/sensors/all.md). Because a rebooting host can't report its own outage, monitor snmp uptime from outside your network with [ostr.io Monitoring](https://ostr.io/service/monitoring) — it remembers the value across the gap and alerts you by email and SMS.