How to Monitor Server Uptime via SNMP

By the SNMP Monitoring team · Reviewed July 2026

Uptime over SNMP answers two different questions that people mash together: “when did the agent restart?” versus “when did the host boot?” Mix those OIDs and you’ll file reboot tickets for snmpd reloads—or miss real reboots entirely.

This how-to separates sysUpTime and hrSystemUptime, converts TimeTicks, detects resets, and explains why uptime alone is not availability. Twin: uptime sensors. Parent: server. Protocol path: how it works.

Two "uptime" values: sysUpTime vs hrSystemUptime

Want “did the server reboot?” → prefer hrSystemUptime. Want “is snmpd fresh?” → sysUpTime helps. Many templates poll both.

Understanding TimeTicks

TimeTicks count hundredths of a second.

• Seconds = TimeTicks ÷ 100
• Minutes = TimeTicks ÷ 6000
• Hours = TimeTicks ÷ 360000

CLI tools often pretty-print “N days, HH:MM:SS.” Your TSDB might store raw ticks—convert before humans read it.

Wrap: TimeTicks is 32-bit in classic SNMP; very long uptimes can wrap. Reboot detection should handle wrap vs true reset carefully (see below).

Reading uptime with snmpget

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0 1.3.6.1.2.1.25.1.1.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (360000) 1:00:00.00
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (8640000) 1 day, 0:00:00.00

Here the host has been up a day while the agent shows one hour—classic “someone restarted snmpd.”

Detecting reboots

Numbered logic that works in practice:

1. Poll hrSystemUptime on a fixed interval.
2. Store last raw TimeTicks (or converted seconds).
3. If new value is much smaller than previous (and not explained by wrap math), treat as reboot.
4. Optionally require two samples so one glitch doesn’t page.
5. Cross-check: agent unreachable during the gap strengthens the case.
6. For agent-only blips, watch sysUpTime reset while hrSystemUptime keeps climbing.

“Counter going backwards” is the operator slang; implement it as a deliberate compare, not as a graph that merely looks steep.

Uptime ≠ availability

A host can have huge uptime and still be dead to users (hung app, full disk, network blackhole on the service port). Conversely, a reboot might be planned.

• Uptime OID = how long since boot/agent init
• Availability = can I reach the service / agent now

External checks and multi-path probes: availability, external monitoring. Poll uptime for reboot forensics; poll reachability for “is it up.”

Reference & CTA

Full leaf notes: sensors/uptime. Alerts: alerts.

For off-box durability, ostr.io reads host uptime 1.3.6.1.2.1.25.1.1.0 externally and can pair frequent + infrequent polls (double durability) so a single missed window doesn’t blind you. Wire-up: setup ostr.io.

One product link; the OID math works in any NMS.

Practical template

• Graph hrSystemUptime (days)
• Event: reboot detected
• Optional: sysUpTime for agent restarts
• Separate ICMP/HTTP check for service availability

Failure modes

• Alerting “reboot” on snmpd restart (wrong OID)
• Displaying TimeTicks as seconds (off by 100×)
• Trusting uptime alone as SLA proof
• Ignoring wrap on long-lived iron

Ops notes

Maintenance windows should annotate expected reboots so you don’t train people to ignore the signal. After crash loops, uptime never climbs—pair with availability flaps.

Also: virtualization live-migration usually keeps guest uptime; that’s not a bug in SNMP. Hardware replace looks like a reboot. Document the platform.

Glossary: glossary.

Worked examples (both OIDs)

Case A — planned snmpd restart: hrSystemUptime keeps rising; sysUpTime resets to near zero. Ticket “server rebooted” is wrong; close with “agent recycle.”

Case B — hard reboot: both drop (host uptime especially). Availability check may flap. Annotate change ticket if planned; if not, start incident.

Case C — hung host still answering SNMP: uptimes climb, but HTTP check fails. Don’t trust uptime green as “healthy.” That’s why availability is a sibling concern.

Case D — agent down, host up: SNMP timeouts; last hrSystemUptime frozen in the UI. Distinguish “stale series” from “uptime zero.” Good NMS mark samples as missing, not zero.

Conversion cheatsheet

Store raw ticks if you want; display days for humans. Alert logic should use comparable units on both sides of the inequality.

Double durability idea (without overselling)

Frequent polls catch reboots quickly; infrequent polls still land if a maintenance window ate your primary path. External host-uptime checks that use 1.3.6.1.2.1.25.1.1.0 fit that story—see the CTA section. Local NMS can mirror the dual cadence if you run two check definitions yourself.

Rollout checklist

1. Add both OIDs to a lab host; label graphs clearly (“host boot” vs “agent”).
2. Restart snmpd only; confirm only sysUpTime resets.
3. Reboot lab host; confirm hrSystemUptime resets.
4. Implement reboot detection in staging with a quiet threshold.
5. Train on-call on the difference using a one-page cheat.
6. Only then enable production paging.

Skip step 2–3 and you will invent phantom reboots for a month.

Display tips

Show host uptime as “up 47 days” not raw ticks. Keep a secondary raw field for debugging. On wallboards, a sea of high uptimes looks great and means little—pair with red availability tiles. Uptime is a forensic and reboot metric first, a vanity metric second.

If hrSystemUptime is missing (minimal agent), say so in the device class note and fall back to sysUpTime with an explicit “agent-only” label—never silently relabel agent uptime as host boot.

Keep a short internal FAQ for the NOC: “Why did uptime reset without a reboot?” Answer #1: snmpd restart. Answer #2: container agent recycle. Answer #3: actual reboot—check hrSystemUptime and hypervisor events. Having that card next to the dashboard stops half the false severity escalations.

Also graph availability on the same board as uptime so green “47 days” never hides a red probe. The metrics answer different questions; showing only one is how vanity boards get built.

Frequently asked questions

What OID is uptime in SNMP?

sysUpTime 1.3.6.1.2.1.1.3.0 (agent) and hrSystemUptime 1.3.6.1.2.1.25.1.1.0 (host). Pick deliberately.

sysUpTime vs hrSystemUptime?

Agent/SNMP engine vs host boot. See the table above.

How do I convert TimeTicks to seconds?

Divide by 100.

How do I detect a reboot via SNMP?

Watch for a sudden drop in hrSystemUptime versus the previous sample (accounting for wrap), ideally confirmed across polls.

Key takeaways

• Two uptimes: agent vs host—don’t mix.
• TimeTicks ÷ 100 = seconds.
• Reboot = uptime reset logic, not a single graph glance.
• Uptime ≠ user-facing availability.
• Twin: sensors/uptime; external host uptime: ostr.io.