What does NTP clock offset actually measure?

Offset is the signed difference between your local clock and the authoritative time source at the moment of measurement. A positive offset means your clock is AHEAD of the reference; negative means BEHIND. Offset is reported in milliseconds or microseconds.

Does a positive offset mean my PC is fast or slow?

Positive offset means your local clock reads a time LATER than the reference — your clock is ahead (running fast since last sync). Negative offset means your clock is behind. NTP will apply an opposite-sign correction to converge back to zero.

What offset value is acceptable?

Internet-facing services: below 100 ms is excellent, 100–500 ms acceptable, above 1 s indicates broken NTP. Active Directory domain controllers: below 5 s required (Kerberos default). Financial and logging environments: below 50 ms. Sub-millisecond precision requires PTP, not NTP.

Why does my live offset drift over time?

Between NTP polls, the system clock runs on the CPU crystal whose frequency drifts with temperature — typically ±10 ppm, or about 1 second per day. A visible drift in the live display between resyncs means NTP correction is happening correctly. A drift that keeps growing indefinitely means NTP is NOT running.

Live NTP Offset | Clock Offset Measurement & Interpretation Guide

1. What live NTP offset measures

NTP offset is the signed difference between your local system clock and an authoritative time source at the moment of measurement. It is the single most important number in time-sync: it tells you by how much, and in which direction, your clock is wrong.

A "live" offset measurement means the value is updated continuously as you watch. On the home page tester, the offset refreshes every 10 seconds, letting you see both the current error and how it evolves between resyncs.

2. Positive vs negative — sign convention

The NTP sign convention (used by chrony, ntpq, w32tm and this tester):

Sign	Meaning	Correction NTP will apply
`+150 ms`	Local clock is 150 ms ahead of reference	Slow the clock (negative frequency step)
`-75 ms`	Local clock is 75 ms behind reference	Speed up the clock (positive frequency step)
`0 ms`	Perfectly synchronised at this instant	Hold frequency

Intuition: the sign of the offset is the opposite of the correction NTP must apply. If you read +150 ms, NTP will slow you down by 150 ms to bring you back to zero.

3. Acceptable offset by use-case

Use-case	Acceptable offset	Breaks at
General desktop / email / browsing	< 1 s	TLS certificates (> ~5 min skew)
Active Directory / Kerberos	< 5 s default	Authentication failure at 5-min skew
TLS / HTTPS certificate validation	< 5 min	Invalid cert errors, OCSP failure
Log correlation / SIEM	< 100 ms	Causality inversion across services
Financial trading (MiFID II RTS 25)	< 1 ms for HFT, < 100 µs for colocated	Regulatory non-compliance
Telecom 5G / PTP-grade	< 100 ns	Synchronisation requires PTP, not NTP

Most applications live comfortably below 100 ms offset — the green zone on the live tester. Anything above 1 second means NTP is effectively broken or absent.

4. How the browser measures offset (HTTPS method)

NTP normally runs over UDP port 123, which browsers cannot send. Our tester uses an HTTPS-based approximation:

Record local timestamp t1 just before sending the HTTPS request.
Server returns its authoritative timestamp t_server (microsecond precision, sourced from a Stratum 1 GNSS).
Record local timestamp t2 on response.
Estimate one-way latency as (t2 - t1) / 2 — the same assumption NTP itself makes.
Compute offset: offset = ((t1 + t2) / 2) - t_server.

This method reproduces NTP's classic four-timestamp algorithm adapted to the request/response pattern of HTTPS. Precision is limited by the symmetry of the TCP/TLS path — typically ±10–30 ms on a good connection, versus ±1 ms for native UDP NTP.

Browser caveat. JavaScript Date.now() has only millisecond resolution, and some browsers quantise it to reduce fingerprinting. Don't expect sub-millisecond precision from a browser-based measurement — for that, use CLI tools directly.

5. Interpreting a drifting live offset

Watch the offset value on the home-page tester for 2 minutes. You should see one of these patterns:

Flat near zero (±5 ms wobble): NTP is running and synchronised. Healthy.
Slow monotonic drift (e.g., +2 ms every 10 s): NTP is OFF or paused. The local crystal is drifting unopposed. Reactivate chronyd / systemd-timesyncd / w32time.
Sawtooth pattern (jumps to zero then drifts up): NTP is running with a long poll interval. Each "jump" is a step correction. Normal for minpoll 10 or higher.
Random jumps of 50–500 ms: high jitter from the network path. See the jitter analysis.
Constant large offset (e.g., +3600000 ms): Timezone mismatch, NOT an NTP issue. Check the TZ configuration.

6. Large or unstable offset — next steps

If the tester reports offset above 1 second or highly unstable values:

Check the NTP service status. systemctl status chrony (Linux), w32tm /query /status (Windows). If it's not running, start it.
Check for firewall blocks on UDP 123. For port-123 and daemon-level issues, use check-ntp.net — the dedicated NTP diagnostic site.
Verify you have at least 4 configured sources. Fewer than 3 active sources means NTP cannot detect a false ticker.
Look at the round-trip delay too. A high offset with a high RTD often indicates a distant or congested source — see the latency benchmark.
Running a regulated workload? For NIS 2 / ISO 27001 / DORA compliance evidence, online-ntp-validator.com produces audit-ready reports.
See a real-world audit. Field case study: 4.2 s of drift brought back under 50 ms across 12 servers (FR).

Run the Live Offset Tester →

Beyond offset? Use the right tool:

Diagnose firewall / port 123 / daemon → check-ntp.net
NIS 2 / ISO 27001 compliance audit → online-ntp-validator.com
Enterprise reference architecture → ntp.rdem-systems.com