← Back to Learning Hub

Office/Network Fixes • Intermediate • 7 min read

Check an NTP Server: Stratum, Offset, and Time Sync Explained

A skewed clock breaks TLS, logins, and 2FA. Learn how to test an NTP server and read stratum, offset, and root dispersion without the jargon.

A clock that drifts by even a minute quietly breaks things that feel unrelated: TLS handshakes fail "certificate not yet valid," time-based one-time passwords (TOTP) stop matching, Kerberos logins are refused, and log timelines stop lining up across machines. NTP (Network Time Protocol) is what keeps every server agreeing on the time, so when something time-sensitive misbehaves, testing your NTP source is a smart early move.

What the numbers mean

Query an NTP server and it returns a small packet with several fields. The NTP server test reads them for you; here is how to interpret each one.

  • Stratum, how many hops the server is from a reference clock. Stratum 1 is directly attached to an atomic or GPS clock. Stratum 2 syncs from a stratum-1 server, and so on. Stratum 0 or 16 means "unusable / not synchronized." For general use, stratum 1-3 is healthy.
  • Offset, the difference between the server's clock and yours, in milliseconds. A few milliseconds is excellent; tens of milliseconds is fine; hundreds of milliseconds or more means one of the two clocks is drifting.
  • Root delay / root dispersion, the total round-trip delay and the estimated error back to the reference clock. Small numbers mean a tight, trustworthy time source.
  • Reference ID, the upstream source. On stratum 1 it is a short code like GPS or PPS; on higher strata it is the IP of the server it syncs from.

Reading a healthy result

A public pool server such as time.cloudflare.com typically comes back around stratum 3, an offset within a few milliseconds of a correctly-set client, and single-digit millisecond root delay. That is exactly what you want to see: reachable, synchronized, and close.

When the offset is large

If the offset is hundreds of milliseconds or seconds, decide which clock is wrong:

  1. Check your own machine against a second, independent NTP server. If both agree that the first server is off, the server is the problem.
  2. If your machine disagrees with several good servers, your machine is the problem, restart its time service and force a sync.
# Linux/macOS: query a server directly
ntpdate -q time.cloudflare.com

# See what your system is actually syncing to
timedatectl show-timesync --all      # systemd
chronyc tracking                     # chrony

# Windows
w32tm /stripchart /computer:time.cloudflare.com /samples:5

Why UDP matters here

NTP runs over UDP port 123. Some restrictive networks block outbound UDP/123, which makes even a healthy server look unreachable. If a test times out, confirm the port is open from your network before blaming the server, a firewall is the more common culprit.

FAQ

What stratum should I aim for?

For clients, syncing to stratum 2 or 3 servers is standard and plenty accurate. You do not need a stratum-1 source unless you are running your own time infrastructure.

My TLS says "certificate is not yet valid", is that NTP?

Very often, yes. If a machine's clock is set in the past, valid certificates look like they have not started yet. Fix the clock, then retry. Confirm the certificate itself with the SSL/TLS certificate checker.

Is a negative offset bad?

No. The sign just tells you which way the clocks differ. What matters is the magnitude, keep it small.

Related guides

Troubleshooting box

If results look inconsistent, compare authoritative nameservers first, then recursive resolvers by region. Capture snapshots every 10 minutes for deterministic incident timelines.

Try VallaDNS free →