NTP & time servers

An NTP monitor asks your time server what time it thinks it is, and compares the answer to real time. It catches the failures that break authentication, certificate validation and distributed databases long before anyone connects them to a clock.

We contact your server. Your server never contacts us. That direction catches people out, so it is worth stating plainly: this works exactly like an HTTP check. You give us a hostname, and every few minutes our probes send it an ordinary NTP query from six regions and read the reply. Nothing is installed, nothing is configured on your side, and we are not a time source — you cannot point a machine at us to set its clock.

What you get

Create an NTP monitor, give it a hostname like time.example.com, and each check records:

• Clock offset — how far the server’s clock sits from real time, signed. +12 ms means it is ahead.
• Our margin — how precisely we could measure that, from that region, on that check. Always shown beside the offset, because it is often larger than the offset itself.
• Stratum — how many hops the server is from a reference clock. Stratum 16 means the server is telling you it is not synchronised at all.
• Root distance — the server’s own stated uncertainty about its time. A server can be 2 ms out and still be admitting it has lost touch with its upstream.
• Reference age — how long since it last heard from that upstream.

The monitor goes down when the offset breaches your limit, when the server declares itself unsynchronised, when root distance exceeds your limit, or when it simply stops answering.

The honest limits

We measure from the public internet, and that costs precision. Our checks are not GPS-disciplined hardware in your rack. Each check’s margin has three parts:

• Our own measurement: about ±3 ms, in every region.
• Half the round trip from the checking region to your server. A server 2 ms away adds about 1 ms; one 50 ms away adds about 25 ms.
• What your server reports about itself (its root distance). A well-synced server reports well under 1 ms; one far from its own reference can report tens of milliseconds.

So the margin is mostly about where your server is and how well it is synced, not about which region checks it. For example, from São Paulo the margin against time.google.com is about 27 ms, because the nearest Google time server answering is about 49 ms away. A well-synced server in São Paulo itself would be checked to within a few milliseconds.

So:

• The tightest limit you can set is 10 ms. Below that even our best regions could confirm a healthy clock only part of the time, so the form refuses it rather than letting you configure something that mostly answers “not measured”.
• Below 40 ms, the form reminds you that the margin depends on your server’s distance and sync. A region whose margin is wider than your limit reports “not measured” while closer regions give a verdict. That is honest reporting, not a fault — and a clock that is badly wrong is still caught from every region.
• 50 ms (the US FINRA CAT tolerance) is the tightest common requirement an external check can serve, from the regions nearest your server.
• “Not measured” is a real answer. It means the check ran, the server answered, and the result sat inside our own uncertainty. It never opens an incident and never counts against your uptime — neither as a pass nor as a failure.

If you need sub-millisecond proof, you do not want an external monitor at all. Trading compliance under MiFID II, broadcast timing under SMPTE ST 2110 and telecom synchronisation all demand accuracy that no internet-based probe can reach. Those need hardware timestamping and local loggers. Run chrony on the host and monitor it there.

And we check the SERVER, not the machines that use it. A healthy answer here proves your time server is serving good time. It does not prove your fleet is reading it — a firewall rule, a stopped chronyd or a daemon that rejected the source will all leave a machine drifting while this monitor stays green. This is infrastructure monitoring for the time service, not a fleet audit.

Who this is actually for

The useful thresholds are far looser than people expect, which is what makes an external check worthwhile:

• Active Directory and Kerberos. The default tolerance for clock skew is five minutes; past it, authentication fails outright and users are locked out. A 500 ms limit gives you days of warning.
• IoT and edge fleets. Devices with dead RTC batteries take their time from your NTP endpoint at boot. If it serves time that is seconds wrong, TLS certificate validation fails across the fleet and nothing can connect.
• Distributed databases. CockroachDB’s default maximum offset is 500 ms, and nodes shut themselves down rather than risk stale reads when they exceed it. An independent outside-in check catches the drift before the cluster does something drastic.
• Public pool members. If you run a server in the NTP pool, serving stratum 16 or a large root dispersion gets you dropped from it. This tells you first.

Against a 500 ms limit even a distant server’s margin leaves plenty of room — and for a nearby, well-synced server it is around 1%.

Settings

Setting	Default	What it does
Clock limit	1000 ms	Alert when the offset is further out than this. Minimum 10 ms.
Server’s own uncertainty	3000 ms	Alert when root distance exceeds this — the server admitting it has drifted from its reference. Matches chrony’s own default.
Maximum stratum	Off	Alert when the server is more than this many hops from a reference. Off by default — a deep hierarchy is not a fault.
Time since last sync	Off	Alert when the server has not heard from its upstream in this long.
Check interval	5 minutes	The minimum. NTP is UDP against machines you do not own, so we poll conservatively.

NTP checks run from six regions rather than the usual city list, and that is fixed for the monitor type. It is not something about your server.

Reading the chart

The 24-hour view plots every reading as a dot, with a faint vertical line through it.

The dot is your clock. The line is our uncertainty. A tall line means we measured from a long way away, not that your clock moved — which is why readings from South America look noisier than readings from Virginia even when the server is rock steady. Nothing below that line can be judged.

There is deliberately no line joining the dots. Consecutive checks come from different regions with different measurement precision, so a connecting line would draw a clock trajectory that never happened, and would paper over the gaps where the interesting failures live.

Above the chart we say how many checks in the window could actually be measured. A chart of four dots drawn from three hundred checks is a very different claim from a chart of three hundred, and the count is the only thing that tells them apart.

On the 30-day and longer views each day shows the average distance from real time, ignoring direction. Direction is deliberately dropped there: a clock swinging +50 ms and −50 ms averages to zero, and would chart as flawless.