How to Check and Fix NTP Time Sync (Windows, Linux, macOS)

— ny_wk

Accurate time feels trivial until it breaks — then suddenly logins fail, certificates are "not yet valid," logs don't line up, and clustered services fall over. Almost all of that traces back to clock skew. NTP (Network Time Protocol) keeps your machines in sync, and checking it takes one command. Here's how to verify and fix time sync on every major OS, plus why it matters more than people think.

Why time sync is non-negotiable

Authentication breaks: Kerberos/Active Directory reject logins when clocks drift more than ~5 minutes. So does much of TLS.
Certificates misfire: a fast clock can see a valid cert as "not yet valid"; a slow one keeps trusting expired ones.
Logs become useless: correlating events across servers is impossible if their clocks disagree.
Distributed systems fail: databases, clusters, and tokens (TOTP/2FA) all assume synced time.

Best practice: where to get time

When possible, use the NTP servers your network advertises via DHCP. Otherwise, point machines at the NTP Pool Project (pool.ntp.org, e.g. 0.pool.ntp.org) or your organization's internal NTP servers. In a domain, member machines should sync from the domain controller hierarchy, and the PDC-emulator from an external source.

Check & fix on Linux

systemd (most modern distros)

Quick status: timedatectl status — look for System clock synchronized: yes and NTP service: active. Enable it: timedatectl set-ntp true.

chrony (RHEL/CentOS/Fedora, increasingly the default)

Check sources and offset: chronyc sources -v and chronyc tracking. Configure servers in /etc/chrony.conf, then systemctl restart chronyd.

ntpd (older systems)

Check peers: ntpq -p — the * marks the selected server, and the offset column shows drift in ms. Config lives in /etc/ntp.conf.

Check & fix on Windows

Windows uses the W32Time service. Check status from an admin prompt:

w32tm /query /status — shows the source and last sync.
w32tm /query /source — which server it's using.

Force a resync: w32tm /resync. Set a manual source: w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /update, then restart the service. (Domain-joined PCs normally sync from the domain automatically — don't override that.)

Check & fix on macOS

Check: sntp -sS time.apple.com or System Settings → General → Date & Time. Set the server with sudo systemsetup -setnetworktimeserver time.apple.com and ensure "Set time automatically" is on.

Reading the numbers that matter

Field	Where	What it tells you
offset	ntpq -p / chronyc tracking	How far off you are (aim for < a few ms)
stratum	tracking / status	Distance from a reference clock (lower = closer)
reach	ntpq -p	377 (octal) = recent polls all succeeded
synchronized	timedatectl	yes = clock is being disciplined by NTP

Common pitfalls

UDP 123 blocked — NTP uses UDP/123; a firewall rule silently kills sync.
Two time services fighting — running ntpd and chrony (or W32Time + a third-party client) causes conflicts. Run one.
VM clock drift — virtual machines drift badly; rely on NTP inside the guest and/or host time sync, not just the BIOS clock.
Huge initial offset not corrected — some daemons refuse to "step" a very large gap; do an initial forced sync (chronyc makestep / w32tm /resync).
Wrong timezone vs wrong time — timedatectl shows both; a timezone mistake isn't an NTP problem.

Key takeaways

Synced time prevents auth failures, cert errors, and unreadable logs — it's foundational.
Check fast: timedatectl status (Linux/systemd), chronyc tracking/ntpq -p, w32tm /query /status (Windows).
Source time from DHCP-advertised servers, pool.ntp.org, or your domain/internal NTP.
Watch for blocked UDP/123, dueling time daemons, and VM drift.

Frequently asked questions

What port does NTP use?

UDP port 123. If sync fails mysteriously, check that it's open outbound.

chrony or ntpd?

chrony is the modern default — faster to sync, better on intermittent connections and VMs. Use ntpd only on legacy systems that already rely on it.

How do I force an immediate resync?

Linux: chronyc makestep. Windows: w32tm /resync. macOS: sudo sntp -sS time.apple.com.

Why do my Kerberos/AD logins fail?

Often clock skew over ~5 minutes. Sync the client's time and logins recover.

One status command tells you if time is healthy; one config line points you at a good source. Make NTP part of your build, and a whole class of "impossible" auth and cert bugs simply never happens.