--- title: Free NTP Server Test description: Query any NTP server from a real probe location and see whether it answers, its stratum, the clock offset and round-trip delay per sample, the leap indicator and the NTP version. Verify a time server before pointing a fleet at it, and catch the one that is reachable but unsynchronised. canonical: https://watchfor.io/ntp-test --- [Back to all free tools](/free-tools) # NTP Server Test Query any NTP server from a real probe location and see whether it answers, its stratum, the clock offset and round-trip delay per sample, the leap indicator and the NTP version. Verify a time server before pointing a fleet at it, and catch the one that is reachable but unsynchronised. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is NTP Server Test ? NTP is how every server, phone and network device agrees on what time it is. A client sends a packet, the server stamps it, and the client computes its clock offset and the round-trip delay. When the time server is wrong or unreachable the symptoms are indirect and expensive: TLS handshakes fail because certificates look not-yet-valid, Kerberos tickets are rejected, log timestamps can't be correlated across machines, two-factor codes stop working, and database replicas disagree about ordering. This tool queries any NTP server from a real probe, takes several samples, and reports what a client would learn: whether the server answers, its stratum (how far from a reference clock), the clock offset and round-trip delay per sample, the leap indicator (synchronised or not) and the NTP version. Use it to verify a time server before pointing a fleet at it, and to catch the one that's reachable but has lost its own sync. ## How it works The same exchange ntpdate -q or chronyc would make: - 1 Send NTP client requests — UDP packets to port 123 (or the one you set), one per sample with a short pause between, from a probe whose own clock is NTP-disciplined. - 2 Read the four timestamps — Client send, server receive, server transmit, client receive. From these the offset (how far the server's clock is from ours) and delay (network round-trip) are computed per sample, as RFC 5905 specifies. - 3 Read the server's self-report — Stratum, leap indicator and version come from the packet header — the server's own statement of its health. Offsets are relative to the probe's clock, which is synced to public stratum-1/2 sources — so a large offset is the server's problem, not ours. ## When you'd use it ### Choosing or verifying a time source Before setting server ntp.example.com on a hundred machines, confirm it answers, reports a sane stratum (2–4 is normal) and has an offset within a few milliseconds of other sources. ### Clocks drifting across a fleet Machines disagree by seconds. Test the server they all use: if its leap indicator says unsynchronised or its stratum is 16, it's been coasting on its own crystal and everyone inherited the drift. ### Firewall and cloud checks UDP 123 outbound is blocked in some networks and some cloud security groups. A test from a probe outside the network shows whether the server is reachable at all from the internet. ### Kerberos, TLS and 2FA failures that mention time Clock skew too great , certificate is not yet valid , TOTP codes rejected. Test the NTP server the affected hosts use before touching anything else. ## Reading the result ### Offset Server time minus probe time. Within ±50 ms is healthy over the internet; hundreds of ms means the server or its upstream is off; seconds means it's not really synchronised. ### Delay and jitter Round-trip time and how much it varies between samples. High or erratic delay makes the offset estimate noisy — normal across continents, suspicious on a LAN. ### Stratum 1 is directly attached to a reference clock (GPS, atomic). 2 syncs from stratum 1, and so on. 16 means unsynchronised; 0 in a response is invalid. Public pools are typically 2–3. ### Leap indicator 0: synchronised. 1 or 2: a leap second is scheduled at the end of the day. 3: the server has no valid time and clients should not trust it. ## Check it yourself ntpdate -q pool.ntp.org Or chronyc -N tracking / ntpq -p on a host to see what it's currently syncing from and how far off it thinks it is. ## Common pitfalls ### Pointing everything at one server NTP clients need three or more sources to detect a lying one. pool.ntp.org resolves to many; a single internal server needs its own upstream sources and monitoring. ### A server that answers but isn't synced Reachable, fast, stratum 16, leap 3. Clients ignore it and drift, quietly. The self-reported fields catch it; a port check wouldn't. ### Blocking UDP 123 for security NTP amplification attacks came from servers answering monlist . Disable that ( restrict … noquery ), don't block time sync for the whole network. ## Run NTP Server Test on every change, not just once. Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions How do I check if an NTP server is working? Send it an NTP request and read the reply: it should answer within a few hundred milliseconds, report a stratum between 1 and 15, a leap indicator of 0, and an offset close to other known-good sources. This test does that from a probe with a disciplined clock. What is a good NTP offset? Under 10 ms on a LAN, under 50 ms across the internet. Anything over a few hundred milliseconds means the server's own sync is poor; over a second means it's effectively unsynchronised. What does stratum mean? Distance from a reference clock. Stratum 1 servers have a GPS or atomic clock attached; stratum 2 sync from them; and so on to 15. Stratum 16 means no synchronisation. Lower isn't automatically better — a well-run stratum 3 beats a badly run stratum 1. Which public NTP servers should I use? pool.ntp.org (and its regional and vendor zones), time.cloudflare.com , time.google.com (note: Google smears leap seconds), time.apple.com , time.windows.com . Use several; let the client pick. Why does the test say the server is unsynchronised? Its leap indicator is 3 or its stratum is 16: it has lost contact with its own upstream sources and knows it. Clients will refuse to sync from it. Fix the server's upstream configuration or network path. Is NTP secure? Plain NTP is unauthenticated; an attacker on the path could feed wrong time. NTS (RFC 8915) adds TLS-based authentication and is supported by Cloudflare, Netnod and others. For most servers, using multiple sources is the practical defence. ## Related network tools - [PingICMP echo request — round-trip time, jitter, packet loss.](/ping-test) - [TracerouteTrace the network path hop by hop with per-hop latency (MTR-style).](/traceroute-online) - [Port CheckerTest TCP port reachability and optionally grab the server banner.](/port-checker) - [Blacklist CheckTest an IP or domain against 15+ DNS-based blocklists (RBLs).](/blacklist-checker) --- Canonical page: https://watchfor.io/ntp-test · Site guide: https://watchfor.io/llms.txt