Problem
In some cases, the uptime displayed in the Site24x7 console may not match the actual uptime shown in the device terminal (via SSH/Telnet). This can lead to confusion, especially for devices that have been running continuously for long periods.
Root cause
Site24x7 retrieves device uptime using the standard SNMP object:
sysUpTime from RFC1213-MIB
This value has a technical limitation:
- sysUpTime is stored as a 32-bit integer.
- Maximum value: 4,294,967,295 timeticks.
- This equals approximately 497 days.
- After reaching this limit, the counter rolls over and resets to zero.
What this means
If a device has been running for more than ~497 days (for example, three–five years):
- The sysUpTime counter would have reset multiple times.
- Site24x7 can only read the current cycle value.
- Hence, the uptime shown in Site24x7 will be lower than the actual device uptime.
Example
- Device actual uptime (from CLI): five years.
- SysUpTime value currently shows: 474 days.
- In ~23–24 days, the counter will reset again to zero.
This is expected behavior due to the SNMP data type limitation.
Additional consideration: SNMP agent restart
The sysUpTime value also resets when the SNMP agent on the device restarts, even if the device itself was not rebooted.
In such cases:
- Terminal uptime (SSH/Telnet) continues correctly
- SNMP-based uptime (used by Site24x7) resets
This can also cause a mismatch between actual uptime and reported uptime.
Is this a Site24x7 issue?
No. This is a known and documented limitation of SNMP (RFC1213-MIB) and applies to all monitoring tools that rely on sysUpTime.
Site24x7 is accurately reporting the value provided by the device via SNMP.
Recommendations
For long-running devices (> one year), treat SNMP uptime as:
- A relative indicator, not absolute lifetime uptime
Use CLI/terminal uptime for:
- Audits
- Compliance reports
- Root cause analysis
Use SNMP uptime in Site24x7 for:
- Detecting recent reboots
- Monitoring availability trends
- Alerting on unexpected restarts
Summary
Source | What it shows |
CLI / SSH / Telnet | Actual device uptime |
Site24x7 (SNMP) | sysUpTime since last SNMP counter reset |
Max SNMP uptime | ~497 days |
After 497 days | Counter rolls over to zero |
This behavior is by design and is a standard SNMP limitation, not a data accuracy issue in Site24x7.
Related Articles
Device types supported for network monitoring
Site24x7 network monitoring offers comprehensive support for a wide range of network infrastructure and hardware platforms. This includes SNMP-enabled devices, modern SD-WAN appliances, IP address management, and agentless server monitoring. Several ...
Why is my network device or agentless server monitor classified incorrectly?
Topics covered in this doc: How are devices classified? Why is the device classified incorrectly and how do I fix it? How are devices classified? When a device is scheduled for discovery using an SNMP credential, we obtain the device identifier of ...
How to check if IPSLA is enabled on a network device
From the machine in which your Site24x7 On-Premise Poller is installed, open the Command Prompt as an administrator (Windows) or the Terminal with root privileges (Linux). Go to the directory where the On-Premise Poller is installed. Navigate to the ...
How to set up alerts for network device data collection issues
When your network monitoring interfaces are not collecting data due to issues in the Network Module, you'll want to be alerted. To set up alerts, you need to add or edit the threshold and availability profile of the On-Premise Poller, which is used ...
FAQ: Network monitoring limits for a single On-Premise Poller in Site24x7
What is the maximum number of network devices and interfaces a single On-Premise Poller can monitor? With the recommended system configuration and the standard polling interval (15 minutes), a single On-Premise Poller can support: 1,500 network ...