What an NTP drift check is
An NTP drift check measures the difference between your computer's clock, our server's clock, and four public NTP servers. Our server sends a small UDP packet to each one on port 123, reads back the timestamps, and computes the offset (how many milliseconds your clock is off) and the round-trip delay.
You get a single view with your machine's time, our server's time, the NTP reference time, and a bar chart of drift per server. Nothing to install, no admin rights, just refresh the page.
How to use it
- Open the tool. Within seconds you see three big numbers: your computer time, our server time, and the NTP reference time (median across the four servers).
- Below them you get two readings: your computer vs NTP and our server vs NTP. A positive value means your clock is slower than NTP. Negative means faster.
- On the right you get a bar chart of drift per server (pool.ntp.org, time.cloudflare.com, time.google.com, time.windows.com). Useful to confirm the servers agree with each other.
- Toggle auto-refresh every 10 seconds with the switch at the top. Off means one-shot measurement, same as pressing "Refresh".
- If a server reports error: timeout, it did not reply in 3 seconds. Often a UDP filter on the path. The other three servers still give you a useful picture.
- The stratum column shows how close to the source that server is. 1 = atomic clock or GPS, 2 = a server querying a stratum 1, and so on. Lower numbers have more authority.
When this is useful
Six situations where clock drift actually hurts:
- TOTP / 2FA fails ("invalid code" even with the right secret) because a phone or server clock drifted by 30+ seconds. You can see immediately whether the problem is on your side.
- TLS certificates marked invalid or "not yet valid" because the server clock is minutes off in either direction and everything breaks.
- Log correlation across microservices - if each node has a different drift, events in Grafana and Loki line up in the wrong order and debugging turns into guesswork.
- Kerberos / Active Directory rejects tickets when the gap between client and domain controller is over 5 minutes (the default clock skew tolerance).
- Multi-master databases (Cassandra, ScyllaDB, CockroachDB) use timestamps to resolve write conflicts - a wrong clock means last-write-wins on the wrong write.
- Smart contracts and blockchain RPCs often validate that block.timestamp is reasonable versus now. A wrong clock on your node = rejected transactions.
Related: world clock, timezone converter, unix timestamp, dns lookup.
Questions and answers
Network Time Protocol is a 1985 protocol (RFC 5905) that lets computers sync their clocks over the network with millisecond accuracy on a LAN and a few tens of ms over the internet. The client sends a small UDP packet to an NTP server, the server replies with timestamps, the client computes offset and delay. Your whole operating system runs an NTP client in the background - on Windows it is W32Time, on Linux usually chrony or systemd-timesyncd, on macOS timed.