Troubleshooting
Linux NTP troubleshooting: fix clock drift and failed time sync
NTP problems show up as more than a wrong wall clock. Time drift can invalidate TLS, break signed tokens, distort logs, confuse distributed jobs, and make incident timelines impossible to correlate across systems.
Measure synchronization state, not only date output
Use timedatectl, chronyc, or the configured time client to check whether the system is synchronized, which sources are selected, offset, reachability, and recent corrections. A clock that looks close by eye can still be outside the tolerance of authentication systems.
Virtual machines should normally use a real time-sync service; occasional hypervisor clock correction is not enough by itself.
Check source reachability and firewall policy
NTP commonly uses UDP 123. Confirm the configured sources resolve and are reachable from the server. Corporate/VPN routing or restrictive outbound rules can isolate time service while web traffic still works.
Use multiple appropriate sources so one unavailable endpoint does not leave the machine drifting indefinitely.
Treat large jumps carefully
A large time correction can affect scheduled jobs, logs, leases, databases, and software expecting monotonic progression. Understand whether the client will step or slew and whether the workload needs a maintenance window for a severe correction.
Fix the underlying source or RTC/virtualization issue if drift repeatedly returns.
Verify dependent systems after recovery
Retest TLS, authentication, scheduled jobs, monitoring timestamps, and distributed application behavior. Alert on unsynchronized state or excessive offset so the next failure is detected before certificates or tokens start failing.
- Check sync status and offset.
- Verify source reachability.
- Understand step versus slew behavior.
- Monitor time health continuously.