desktest.net
GitHub

Clock Test Guide

A reference for the desktest.net Clock Test. The tool measures how far this computer's clock is off from a trusted time source, and tells you whether that gap is big enough to break HTTPS, domain logins, or time-based 2FA. Use it when a login "just started failing" and nothing else changed.

Open the Clock Test ->

What does the Clock Test check?

The tool answers one question: is this computer's clock close enough to real time that time-dependent security still works? A surprising number of "cannot log in" and "certificate error" tickets come down to a clock that has drifted by minutes. Three steps run in order:

  1. Reach the time source. Fetches trusted edge time from edge.desktest.net/time (a Cloudflare Worker) with an 8 second timeout. This confirms there is a reference to compare against before anything is measured.
  2. Measure your clock offset. Takes five timed round-trips to the time source. For each, it records the local time it sent the request and the local time it got the reply, reads the server's timestamp, and computes the difference. It keeps the fastest round-trip because that sample has the least network noise. A positive offset means your clock is behind (slow); a negative offset means it is ahead (fast).
  3. Is the clock usable? Compares the absolute offset against two thresholds: 2 seconds (accurate) and 90 seconds (2FA risk). Above 90 seconds it is treated as severe because that is enough to break HTTPS and domain logins.
Your clock reading never leaves the browser. The test only reads trusted time from the edge; it does not send your local time anywhere. The offset math happens entirely in the page.

When should I run this?

Reading the results

Each step renders a row with a status badge: Pending (grey), Running (yellow), Pass (green), Warn (yellow), or Fail (red). Step 2 expands to show your clock reading, the trusted time, the offset in plain language and in raw milliseconds, the best round-trip time, and how many samples were used.

The verdict panel at the top summarises the run with a likely cause and a recommended next step. The three outcomes map directly to the thresholds:

Offset (absolute)VerdictWhat it means
2 seconds or lessPassAccurate. HTTPS, logins, and 2FA all validate.
Over 2 seconds, up to 90 secondsWarnTime-based 2FA (TOTP) codes may be rejected. Nudge the clock back in sync.
Over 90 secondsFailBreaks HTTPS certificate validation, Kerberos/AD logins, and 2FA.

Copy Diagnostic Report copies a plain-text report: timestamps, user agent, your clock, the trusted time, the offset in milliseconds and in words, the best round-trip, the sample count, and the named diagnosis. Paste it into a ticket or an email to IT.

Common failures and fixes

Each outcome produces a specific named diagnosis. Each diagnosis maps to a concrete fix. They are listed below in the order of severity.

clock-ok: within a couple of seconds

The absolute offset is 2 seconds or less. Nothing to fix. Your clock agrees with trusted time closely enough that certificate validation, Kerberos, and TOTP all work. A second or two of apparent offset is normal and comes mostly from network round-trip, not a real clock error.

clock-skew-2fa: off by 2 to 90 seconds

The clock is off by more than a couple of seconds but less than 90. HTTPS still works at this size, but time-based one-time codes (Google Authenticator, Microsoft Authenticator, Authy, hardware TOTP tokens) are generated in 30-second windows from the current time. An offset this large can push a code into the wrong window, so logins that ask for a 6-digit code start failing on and off.

  1. Windows: Settings > Time & Language > Date & Time > click Sync now. Confirm the time zone is correct too.
  2. macOS: System Settings > General > Date & Time > enable Set time and date automatically.
  3. Phone authenticator apps have their own time-sync setting. In Google Authenticator: Settings > Time correction for codes > Sync now. The app corrects its own offset without changing the phone clock.
  4. If the offset comes right back after syncing, the CMOS/RTC battery may be failing (desktops) or a VM is drifting against its host. See the admin section below.

clock-skew-severe: off by more than 90 seconds

The clock is off by more than 90 seconds. This is large enough to break core security checks that depend on the current time:

  1. Windows: Settings > Time & Language > Date & Time > click Sync now, and set the time zone correctly.
  2. If it keeps drifting after syncing, the CMOS/RTC battery may be dead (common on older desktops) or a VM is drifting against its host clock.
  3. Domain PCs sync time from the domain controller, so a broken w32time service or blocked NTP (UDP 123) leaves them adrift. Have IT check the Windows Time service (see below).
  4. macOS: System Settings > General > Date & Time > enable Set time and date automatically and pick the correct time zone.

time-source-unreachable: could not read trusted time

The test could not reach edge.desktest.net/time, so there is no reference to compare your clock against. This is a network problem, not a clock problem: the offset simply cannot be measured without a reply from the time source.

  1. Confirm the workstation is online. Open any HTTPS site in a normal tab.
  2. If a corporate proxy or firewall is in the path, it may be blocking edge.desktest.net. Ask your network admin to allow it on port 443.
  3. Run the Network Test to confirm basic egress works, then come back and re-run this test.
  4. If on a VPN, disconnect and re-test. A half-up tunnel commonly blocks egress while the routing table still claims the link is up.

For IT admins

The test page loads through whatever corporate proxy sits between the user and the public internet. If it does not load at all, allow desktest.net through the edge first. The page has no third-party scripts, no analytics, and no CDN fonts, so there is nothing else to allow-list for it to render. The only origin the diagnostic talks to is edge.desktest.net on port 443 (plain HTTPS GET, no WebSocket for this tool).

Windows Time service (w32time)

Domain-joined Windows machines do not use public NTP by default. They sync up the domain hierarchy: workstations and member servers get time from a domain controller, DCs get it from the PDC emulator for the domain, and the forest-root PDC emulator is the authoritative source that should point at a real external time source. When a machine is badly off, the usual culprits are:

Kerberos and the 5-minute skew limit

Kerberos timestamps every authentication request to defend against replay. If the client clock and the KDC (domain controller) clock differ by more than the allowed skew (5 minutes by default, set by the Maximum tolerance for computer clock synchronization policy), the ticket request is rejected. The symptom is a machine that reaches the network fine but cannot log in to the domain, cannot open mapped drives, and fails SSO. This tool's 90-second "severe" threshold is deliberately tighter than the 5-minute Kerberos limit so you catch drift before it crosses the line.

Hardware and virtualization causes

Behind the scenes

The measurement is a lightweight version of what NTP does. For each sample the tool records t1 = Date.now() just before the request, fetches edge.desktest.net/time with cache: 'no-store', reads the server's serverEpochMs from the JSON reply, and records t4 = Date.now() when the reply lands. It assumes the server read its clock at the midpoint of the round-trip, so the offset is serverEpochMs - (t1 + t4) / 2 and the round-trip time is t4 - t1.

Five samples are taken and the one with the smallest round-trip is kept. A fast round-trip means less time spent unknown-in-transit, so its midpoint assumption is the most accurate and the offset estimate is tightest. This is why a slow or jittery connection does not fool the result: the noisy samples are discarded. Because the offset math must compare against the same clock that produced t1 and t4, the tool uses Date.now() (wall-clock epoch) rather than performance.now() (a monotonic timer with no epoch).

A positive offset means the local clock is behind trusted time (slow); a negative offset means it is ahead (fast). The "trusted time" shown in the results is simply your clock plus the measured offset, that is, what your clock should read right now. No local time value is ever transmitted; the browser only receives the server timestamp and does the comparison itself. View the page source to confirm the single endpoint and that nothing else is contacted.

Elsewhere on the web: