Overview
This article explains why Device Uptime or Last Boot Time in LiveEdge® Cloud may appear incorrect after a Node device reboots.
This behavior usually occurs when the device cannot connect to an NTP (Network Time Protocol) server during startup. It affects time reporting in LiveEdge® Cloud but does not affect streaming performance or indicate hardware failure. However, an incorrect system time may cause significant connectivity issues.
Use this article to identify the cause, configure a reliable NTP server, and verify that the device reports the correct boot time.
Key benefits
Identify why Device Uptime or Last Boot Time may be incorrect.
Improve time synchronization on Node devices.
Prevent inaccurate uptime reporting after future reboots.
Affected products
LiveEdge® Node and EZ Node.
Supported protocols and standards
NTP (Network Time Protocol)
Requirements
Access to the Node Web UI
A reachable local or public NTP server
Network and firewall access that allows the device to reach the NTP server
Access to LiveEdge® Cloud to verify Device Uptime and Last Boot Time
Table of contents
Common use cases
Use case |
Summary |
| Incorrect uptime after reboot | The device appears to have been running longer than it actually has. |
| Last Boot Time does not update | The Node was unable to synchronize its system time during startup. |
| Remote or cellular deployment | Network connectivity may not be available when the device starts. |
| Device moved to another network | The configured or default NTP server may no longer be reachable from the new network. |
Troubleshooting
Symptom |
Likely cause |
Resolution |
| Device Uptime is longer than expected | The device did not obtain an NTP lock during startup. | Configure a reachable NTP server and reboot the device. See the FAQ below for server examples. |
| Last Boot Time does not update | Network connectivity was unavailable during startup. | Ensure the router is fully booted and capable of establishing a network connection before powering on the Node. |
| Time remains incorrect after changing the NTP server | The settings have not taken effect yet. | Save the settings, reboot the device, and verify the time in LiveEdge® Cloud. |
| The NTP server cannot be reached | A firewall rule may be blocking NTP traffic. | Confirm that outbound NTP traffic can reach the configured NTP server and receive its response. |
Best practices
Use a locally managed NTP server in enterprise environments.
Confirm network connectivity before powering on the Node.
Use an NTP server that is geographically close to the deployment location.
Avoid unnecessary reboots during live production events.
FAQ
Q: Why does my LiveEdge Node show the wrong uptime after a reboot?
A: The device may not have connected to an NTP server during startup. Without synchronized system time, it may record an incorrect boot timestamp.
Q: Does incorrect Device Uptime affect streaming?
A: No. Incorrect uptime or boot-time reporting does not affect streaming performance or indicate a hardware failure. However, an incorrect underlying system time may affect connectivity and other time-sensitive services. Check the related documentation for help.
Q: Which NTP server should I use?
A: Use a reliable NTP server that is reachable from the device’s network. A locally hosted server is recommended for enterprise environments. A public server such as time.google.com may also be used.
Q: Do I need to reboot after changing the NTP server?
A: Yes. Save the new NTP settings, reboot the device, and confirm that Last Boot Time has updated correctly in LiveEdge® Cloud.
Related documentation
Keywords and alternative terms
Also known as: incorrect Node uptime, incorrect last boot time, NTP synchronization failure, NTP lock, Node system time, LiveEdge Cloud uptime, Node boot timestamp.