Wrong server time: how to check clock synchronisation

Compare the same time rather than different time zones

The date -u command displays system time in UTC. Also run timedatectl status and record the date, time zone and synchronisation status. Different local displays do not necessarily mean a clock is running slow. Changing the time zone does not replace fixing synchronisation. Identify the service managing time on this host; displaying the clock alone does not show its offset from a time source.

Certificate validation checks the period between notBefore and notAfter against the current time. JWT uses exp for expiry and nbf for the start of validity when those claims are present. Check the clock on the client or validating backend too. During diagnosis, keep validity checks enabled and avoid automatically extending token lifetimes. First record the exact error and compare the times.

Check the measurement and the source's reachability

With chrony, start with chronyc tracking. The System time field reports the difference between the system clock and the time maintained by chrony; it is not interchangeable with Last offset. Check Leap status too, which can report Not synchronised. Save the output and compare it with a later measurement. One small number without the surrounding information is insufficient to assess synchronisation.

The chronyc sources -v command shows the sources in use. An asterisk marks the selected source; a question mark can mean an unreachable or unsynchronised source, or insufficient measurements. If responses are missing, check DNS and the NTP packet path, including the firewall. Ordinary NTP requests go to UDP port 123. Working HTTPS access alone does not establish that this communication works.

Distinguish gradual correction from a clock step

Chrony normally corrects time gradually by adjusting the clock's rate. The makestep mechanism permits a clock step; its configuration directive can restrict this to the first updates after chronyd starts. The documentation warns that time jumps affect some applications. For a large offset, first identify its cause and assess how the running services will handle the correction.

Do not copy a startup correction configuration into a live incident without assessing it. Record the state before the change, prepare a procedure for dependent services, then check synchronisation and the previously failing operation again. If you restore a source's reachability, also monitor whether the clock is actually being corrected. Network responses returning do not complete the diagnosis on their own.

Monitor the offset and measure durations correctly

To measure an operation's duration, use suitable monotonic clocks available in your runtime. Linux CLOCK_MONOTONIC is unaffected by a sudden system time jump, although frequency adjustments affect it. For event timestamps, keep calendar time with an explicit time zone and host identifier. A request's duration and the time it started are different pieces of information.

Include the offset and synchronisation state in your operational view. Choose an alert threshold based on the application's requirements rather than a universal number of milliseconds. After a restart or source change, check that measurements continue. During an incident, compare this state with TLS errors, token validation failures and logs from the affected hosts.

• Record UTC and distinguish a time zone error from a clock error.
• Check chrony, the selected source and NTP responses.
• Assess the effect of correction before stepping the clock.
• After the change, check synchronisation and the original user operation.