SNMP Uptime OID: sysUpTime vs hrSystemUptime Reference

By the SNMP Monitoring team · Reviewed July 2026

There are two "uptime" OIDs in SNMP and they measure different clocks — mixing them up is behind a lot of confused reboot alerts. sysUpTime counts since the SNMP agent restarted; hrSystemUptime counts since the host booted. Restart snmpd without rebooting and the first resets while the second keeps climbing. This page is the paste-ready reference for both, plus how to decode the TimeTicks they return.

The "how do I alert on a reboot" side is the twin: monitor uptime. Hubs: sensors, all OIDs.

sysUpTime

The one everyone quotes. sysUpTime (also exposed as sysUpTimeInstance) is the time since the SNMP agent last (re)initialised.

Because it tracks the agent, a sysUpTime that suddenly drops toward zero means the agent restarted — which usually (but not always) means the box rebooted. It's cheap to poll and doubles as a liveness check: if it answers at all, the agent is alive.

hrSystemUptime

The HOST-RESOURCES counterpart, which tracks the actual host boot:

This is the one to use when you genuinely mean "how long has the machine been up," independent of any snmpd restart. It's also what the external check reads via external monitoring for host uptime.

Comparison

Same type, different clock — this is the whole point of the page:

The practical difference: restart snmpd for a config change and sysUpTime zeroes while hrSystemUptime keeps counting. If you alert on the wrong one you'll either miss reboots or fire false "reboot" alerts every time the agent bounces.

Which one should you poll?

It depends on the question you're actually asking, and the two are not interchangeable:

• "Did the machine reboot?" — use hrSystemUptime. It only resets on a real boot, so a drop is an unambiguous reboot signal. This is the one you want behind a reboot alert.
• "Is the agent responding, and how long has it been up?" — use sysUpTime. It's the lightest object on the box, present in every SNMP implementation (even minimal embedded agents that skip HOST-RESOURCES), so it's the safest liveness probe.
• "I need one uptime that works on anything" — sysUpTime is the more universally implemented of the two. A switch or appliance may not answer hrSystemUptime while it always answers sysUpTime.

There's a subtlety worth internalising: a reset in sysUpTime does not prove a reboot, because the agent can restart on its own (a package update, a crash-and-respawn, a manual systemctl restart snmpd). Only hrSystemUptime returning to near-zero tells you the host went down. On gear that lacks hrSystemUptime, you can still infer a reboot from sysUpTime — but treat it as "probable reboot," and corroborate with other signals like availability checks or a syslog boot message before you page someone at 4 a.m. That distinction is exactly why both objects exist rather than one.

TimeTicks explained

Both objects are TimeTicks — counted in hundredths of a second (centiseconds), not seconds. So the raw number is 100× the seconds. Conversions:

• Seconds = TimeTicks ÷ 100
• Minutes = TimeTicks ÷ 6,000
• Hours = TimeTicks ÷ 360,000
• Days = TimeTicks ÷ 8,640,000

Most tools print a human string next to the raw ticks (e.g. 102 days, 8:22:17), but if you're doing math on the value yourself, remember it's centiseconds. To decode a raw TimeTicks value to days:

1. Take the raw value (e.g. 884213700).
2. Divide by 100 to get seconds (8,842,137).
3. Divide seconds by 86,400 to get days — or divide the raw value by 8,640,000 directly.
4. Result: 884213700 ÷ 8,640,000 ≈ 102.3 days.

One more wrinkle: TimeTicks is a 32-bit unsigned counter, so it wraps after about 497 days. A box up longer than that shows a value that has rolled over — don't read a small sysUpTime as "just rebooted" without sanity-checking against hrSystemUptime or a known boot time. This wrap is a real gotcha on long-lived infrastructure like core switches and routers that can stay up for years: a naive reboot check keyed purely on "uptime got smaller" will fire a false alarm roughly every 497 days on a box that never actually rebooted. Anchoring the alert to a known boot timestamp, or corroborating with a second signal, sidesteps it.

Worked snmpget example

Both objects are scalars, so snmpget with the trailing .0:

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: (884213700) 102 days, 8:22:17.00
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (884235500) 102 days, 8:25:55.00

Here they're close — the host and agent came up together. When sysUpTime is small but hrSystemUptime is large, snmpd was restarted without a reboot. <RO_string> is a placeholder; keep live communities out of committed scripts.

How to monitor uptime (how-to)

Reference stops here. The alerting logic — detecting a reboot from a counter reset, distinguishing agent bounce from host reboot, tying uptime into availability — is the twin: monitor uptime via SNMP. Related: availability monitoring, the OID basics, the OID catalog, and glossary.

Frequently asked questions

What is the OID for uptime in SNMP?

Two of them: sysUpTime at 1.3.6.1.2.1.1.3.0 (time since the SNMP agent restarted) and hrSystemUptime at 1.3.6.1.2.1.25.1.1.0 (time since the host booted). Both return TimeTicks in hundredths of a second. Use hrSystemUptime when you mean actual machine uptime.

What's the difference between sysUpTime and hrSystemUptime?

sysUpTime tracks the SNMP agent's runtime, so it resets when snmpd restarts — which can happen without a reboot. hrSystemUptime tracks the host's runtime since boot, so it only resets on an actual reboot. Restart the agent for a config change and the two diverge.

What are TimeTicks?

A TimeTicks value counts hundredths of a second (centiseconds) since some event. It's a 32-bit unsigned counter, so it wraps after roughly 497 days. To get seconds, divide by 100; for days, divide by 8,640,000.

How do I convert TimeTicks to days?

Divide the raw TimeTicks value by 8,640,000 (that's 100 ticks/second × 86,400 seconds/day). For example, 884213700 ÷ 8,640,000 ≈ 102.3 days. For seconds, divide by 100 instead.

Key takeaways

• sysUpTime (1.3.6.1.2.1.1.3.0) = SNMP agent runtime; resets on snmpd restart.
• hrSystemUptime (1.3.6.1.2.1.25.1.1.0) = host runtime since boot; use this for real uptime.
• Both are TimeTicks (centiseconds): seconds = ÷100, days = ÷8,640,000.
• TimeTicks is 32-bit and wraps at ~497 days — sanity-check a small value.
• sysUpTime doubles as a liveness probe; a drop toward zero flags an agent/host restart.
• Procedure: uptime how-to; catalog: sensors/all.