What happens if a server's clock is wrong?

Certificate validation fails because validity windows are compared against local time, signed tokens are rejected as expired or not yet valid, schedulers and retry logic misbehave, and log timestamps stop being usable for establishing sequence. The failures appear as trust and authentication problems rather than as time problems.

What caused the July 2026 Telstra outage?

The Register reported that an NTP server with a faulty GPS card reset its internal clock to 2006 on restart and then distributed that time across the network. Downstream equipment compared certificates against the incorrect date, judged them invalid, and refused connections.

How do you prevent a bad time source from spreading?

Configure clients with multiple independent sources so an outlier can be discarded, and set sanity bounds so implausibly large adjustments are refused or flagged rather than applied. Monitoring clock offset as a metric turns this from an invisible fault into an immediate alert.

Why are clock problems hard to diagnose?

Because the symptoms point elsewhere. Simultaneous TLS handshake failures and authentication rejections each have more common explanations, which responders reasonably pursue first. The useful signal is the breadth: several unrelated subsystems failing on trust grounds at once suggests a shared dependency.

Should time servers be treated as production infrastructure?

Yes. They have owners, patch requirements, change control, and documented failure behaviour like anything else, and the contributing factors reported in this incident included an undocumented change and an available update that had not been applied. Restart behaviour deserves explicit testing.

Time as a Failure Mode

An incorrect clock breaks certificate validation, token expiry, scheduling, and log correlation simultaneously, because all of them compare timestamps. In the July 2026 Telstra outage reported by The Register, an NTP server with a faulty GPS card reset its clock to 2006 and distributed that time, after which downstream equipment rejected connections on certificate grounds.

What the postmortem reported

The Register reported in July 2026 on an Australian mobile network outage on 7 and 8 July 2026 caused by a network time protocol server whose internal clock reset to 2006. According to that reporting, the server had a faulty GPS card, and on restart during maintenance it came up with a clock set to 2006 and then published that time across the network, as an NTP server is designed to do.

The consequence was not that things were scheduled wrongly. Downstream equipment compared digital certificates against the bogus date, concluded the certificates were invalid, and denied connections. The outage affected mobile service broadly, and The Register reported that emergency calls, electronic payments, and transport were disrupted.

The reported timeline is instructive: maintenance began shortly before midnight, the server powered up at 03:38, it was isolated at 07:11, and the cause was fully identified at 10:30. Contributing factors reported include an undocumented design change made to fix an earlier fault, an available software update that had not been applied, and a maintenance team unaware of how the device would behave after restart. Telstra described the outage as clearly unacceptable in a submission to a Senate inquiry, citing inadequate controls and documentation.

A detailed explanation involving the GPS week number rollover circulated, including in a Netnod blog post whose title gave this incident its memorable phrasing. That specific arithmetic is not in The Register's account, which reports only a faulty GPS card and a reset to 2006, so it is worth treating as one proposed mechanism rather than an established fact.

Why the symptoms point away from the cause

The three and a half hours between the server coming up and being isolated is the interesting part, and it is not incompetence. A wrong clock does not announce itself. It presents as TLS handshake failures, expired tokens, and authentication rejections across unrelated systems at once. Every one of those symptoms has a more common explanation, and responders pursue those first. The breadth is the actual signal: when several unrelated subsystems fail on trust grounds simultaneously, a shared dependency is more likely than a coincidence, and time is the shared dependency nobody has on the diagram.

What depends on the clock

Certificate validity windows. Every TLS certificate has a not-before and not-after date, and validation compares them against local time. A clock in the past rejects currently valid certificates; a clock far in the future rejects them as expired. Either way the failure looks like a certificate problem.

Token and session expiry. Signed tokens carry issue and expiry claims. Skew beyond the allowed tolerance means tokens are rejected as not yet valid or already expired, which surfaces as widespread authentication failure.

Scheduling and retries. Cron-style schedulers, backoff calculations, and rate limiters all derive from the clock. A large jump can cause a scheduler to conclude it missed a great many executions and attempt them at once.

Log correlation and forensics. During an incident, timestamps are how you establish sequence. Wrong clocks produce timelines where effects precede causes, which is its own trap during an investigation.

Distributed coordination. Leases, locks, and consensus protocols use timeouts. Clock jumps can cause a node to believe a lease has expired or to hold one past its intended end.

Certificate and credential rotation. Automation that renews certificates before expiry makes its decision from the clock, so a wrong clock can either renew constantly or believe there is no urgency.

Controls worth putting in place

Multiple independent time sources, and a quorum. A client configured with several upstream servers can discard an outlier. A client with one authoritative source has no defence, and the protocol's selection algorithms only help when there is something to select between.

Sanity bounds on accepted adjustments. Most implementations can be configured to refuse or to flag adjustments beyond a threshold, or to exit rather than step the clock by an implausible amount. A jump of years should never be applied silently, and this single setting prevents the most severe version of this failure.

Monitor offset as a first-class metric. Alert on the difference between local and reference time, on stratum changes, and on a source becoming unreachable. Offset is cheap to collect and rarely graphed, and it is the metric that would have named the cause immediately.

Test restart behaviour explicitly. Time sources misbehave on cold start, when a hardware clock may be wrong and the reference has not yet been acquired. A device that serves time before it has a trustworthy source is the specific hazard, and hardware degradation makes this more likely over years than on day one.

Treat time infrastructure as production. Patching, ownership, change records, and documentation. The reported contributing factors here, an undocumented change and an unapplied update, are ordinary operations gaps rather than exotic ones.

Put time in the incident checklist. When unrelated systems fail authentication or TLS simultaneously, check clock offset early. It is a ten second check that is rarely made.

Alert on certificate validity independently of the clock you are validating with. External monitoring that observes your endpoints from outside distinguishes an expired certificate from a wrong local clock, which is exactly the distinction that is hard to make from inside.

Frequently asked questions

What happens if a server's clock is wrong?: Certificate validation fails because validity windows are compared against local time, signed tokens are rejected as expired or not yet valid, schedulers and retry logic misbehave, and log timestamps stop being usable for establishing sequence. The failures appear as trust and authentication problems rather than as time problems.
What caused the July 2026 Telstra outage?: The Register reported that an NTP server with a faulty GPS card reset its internal clock to 2006 on restart and then distributed that time across the network. Downstream equipment compared certificates against the incorrect date, judged them invalid, and refused connections.
How do you prevent a bad time source from spreading?: Configure clients with multiple independent sources so an outlier can be discarded, and set sanity bounds so implausibly large adjustments are refused or flagged rather than applied. Monitoring clock offset as a metric turns this from an invisible fault into an immediate alert.
Why are clock problems hard to diagnose?: Because the symptoms point elsewhere. Simultaneous TLS handshake failures and authentication rejections each have more common explanations, which responders reasonably pursue first. The useful signal is the breadth: several unrelated subsystems failing on trust grounds at once suggests a shared dependency.
Should time servers be treated as production infrastructure?: Yes. They have owners, patch requirements, change control, and documented failure behaviour like anything else, and the contributing factors reported in this incident included an undocumented change and an available update that had not been applied. Restart behaviour deserves explicit testing.