Why does my Linux clock keep drifting out of sync?

Diagnose and fix Linux clock drift and NTP sync issues using chrony, timedatectl, and network checks.

Linuxtimedatectltimezonetime-syncsystemdDiagnosticschronyMedium risk
First check whether chrony is actually synced with `chronyc tracking`; if the reference ID is .LOCL or the offset is large, your clock is not being corrected.

What this covers

Linux clock drift usually means NTP or chrony isn't syncing, or the timezone is misconfigured. Work through the checks below to find the cause and fix it.

Symptom

?System time slowly drifts away from real time; logs have wrong timestamps; scheduled tasks fire at odd times; `timedatectl` shows NTP service inactive or sync pending.

Check whether chrony is actually syncing your clock

This is the fastest way to see if your clock is being corrected. The tracking output shows the current offset, stratum, and reference server; the sources output lists which NTP servers are reachable. If the reference ID is .LOCL, the stratum is 0, or the offset is seconds instead of milliseconds, NTP is not working.

Verify that chrony is keeping the clock accurate and which NTP servers it uses.

Command
$ chronyc tracking && chronyc sources -v

Correct the timezone if it is wrong

Clock drift and wrong timezone are different problems, but a misconfigured timezone makes every timestamp look wrong and can confuse your diagnosis. Use timedatectl to set the correct timezone, then check that the NTP service is enabled and active. This step is optional if your timezone is already correct.

LinuxSet the Timezone with timedatectlMedium riskStep 2Optional

timedatectl lists, sets, and verifies the system timezone and NTP sync status on systemd distributions.

Command
$ sudo timedatectl set-timezone Asia/Shanghai
▾ Undo
Undo
$ sudo timedatectl set-timezone UTC

Verify network stability to your NTP server

NTP needs a stable network path. Run a continuous ping to the NTP server or your gateway and watch for packet loss or large latency spikes. If replies are steady and timestamps are consistent, the network is not the reason sync fails; if you see loss, fix the network before expecting NTP to hold time.

Keep pinging a host until interrupted while printing a Unix timestamp on every reply — perfect for correlating packet loss with events.

Command
$ ping -D 8.8.8.8
!Changing the timezone can shift timestamps in logs and cron jobs. Do not manually set the clock forward or backward on a running system with databases; use NTP to slew the time instead.

How to confirm it worked

Run `chronyc tracking` again and confirm the offset is small (under a few milliseconds), the stratum is not 0, and the reference ID is a real NTP server. Also check `timedatectl` shows NTP synchronized: yes.

Undo everything

Every command above can be reverted. Run these in order to undo all of it.

Undo everything
$ sudo timedatectl set-timezone UTC

Review before running — some steps may not be independent.

Sources

  • chrony documentation
    chrony project · community · 2026-09-17
    Evidence: Official documentation for the tracking and sources commands and the meaning of Leap/Stratum/Root delay fields.
  • timedatectl(1) - Linux manual page
    Ubuntu Manpages · technical · 2026-09-17
    Evidence: timedatectl set-timezone sets the system timezone, list-timezones shows available zones, and set-ntp controls network time synchronization.
  • ping(8) — send ICMP ECHO_REQUEST to network hosts
    man7.org · technical · 2026-09-17
    Evidence: Documents -D to print timestamps before each line and -i interval / -c count semantics.
  • chronyc(1) - command-line interface for chrony
    Ubuntu Manpages · community · 2026-09-17
    Evidence: chronyc tracking reports system time, last offset and stratum; chronyc sources shows the NTP servers chrony is using and their reach/state.

Last verified: 2026-09-22

Related guides