Telstra outage traced to a GPS card that thought it was 2006

On 8 July 2026, a large part of the mobile network run by Telstra, Australia's largest cell phone operator, stopped working: voice calls and text messages failed to go through, calls to Australia's emergency number did not connect, and the disruption reached well beyond phones, into trains, payment terminals, ticketing systems and EV chargers. Telstra commissioned an independent review from Technology Audit Partners (TAP), and a blog post by Sven-Christian Ebenhag of Netnod, Sweden's national time-distribution operator, published 17 September 2026, walks through what that report found. Nothing was attacked, no fiber was cut, and every system had power. The cause was a single GPS receiver in a single chassis in Melbourne that, coming back from scheduled maintenance, believed the year was 2006, and the rest of the network was persuaded to believe it too.

Telstra's mobile core keeps time through Network Time Protocol (NTP), which ranks sources in strata: stratum 0 is a reference clock such as a GPS receiver, stratum 1 syncs directly to it, and each further stratum syncs from the one above. Telstra's 2010 design put stratum 1 sources at Australia's National Measurement Institute (NMI) at the top, feeding two stratum 2 servers, in Sydney and Melbourne, which in turn fed three stratum 3 servers, in Sydney, Melbourne and Perth. NTP defends itself against a bad clock two ways: a lower stratum outranks a higher one, and a source that disagrees with the rest gets voted down as an outlier. Both defenses only work if the sources being compared are genuinely independent of each other.

A 2020 upgrade undid that independence in two steps. New chassis hardware could not let a stratum 2 server feed a stratum 3 server inside the same box, so Sydney's stratum 3 server was rewired to take time from Melbourne's stratum 2, and Melbourne's from Sydney's, leaving each site with one stratum 2 source instead of two. TAP's report states this loss of redundancy was known and accepted at the time. Telstra also dropped the original directional client/server model for symmetric peering, where nodes settle on whichever source their algorithm currently favours; the report does not state why, though the author's own guess is that peering was meant to offset the redundancy just lost. Peering opened the door to a "timing loop," where sources that look independent are secretly circular, and TAP found no evidence anyone had assessed that risk.

By October 2025, Melbourne was repeatedly losing contact with its one remaining Sydney source. To fix it, two engineers activated a GPS receiver that had sat unused in the Melbourne chassis since 2020 and wired it in as a replacement; both were off duty on mandatory stand-down before anyone worked out what the change had actually done to the network. The alarms stopped and the fix looked complete, but nobody established why Melbourne kept losing Sydney in the first place, and nobody registered that attaching a GPS card promoted the Melbourne server from stratum 3 straight to stratum 1, the same rank as NMI itself. From that point, Melbourne's box was the single most authoritative source in the hierarchy, and every source that could have contradicted it now sat downstream of it.

GPS itself supplied the second half of the failure. It broadcasts time as a week count from a January 1980 epoch, and the week-number field in the main civil signal is only 10 bits, a maximum of 1,023 weeks, so the counter rolls over every 1,024 weeks, about 19.6 years; that has already happened twice, in August 1999 and April 2019. The Melbourne card sailed through the 2019 rollover without issue because it never stopped running, and a receiver that keeps counting never has to guess which epoch it is in. Powering it down and back up for the July 2026 maintenance changed that: on restart, the card had to derive the epoch from its firmware alone, and that firmware, unpatched for six years despite a rollover fix the vendor had already published, defaulted to the earlier epoch. It set its clock 1,024 weeks in the past, to November 2006.

Because the Melbourne server was by then both the highest-ranked source in the hierarchy and structurally unopposed, both of NTP's defenses failed at the moment they were needed. The lower-stratum rule steered every client toward the one source that was wrong. The outlier check never engaged, because nothing independent was left to disagree with it; the servers that should have held onto 2026 were downstream of Melbourne and simply echoed the date back once enough of the network had adopted it. Once a majority of a client's sources agreed on November 2006, each client accepted it, and the further the wrong date travelled, the more sources appeared to confirm it.

TAP's published review, and Ebenhag's reading of it, draw a set of operational lessons: treat timing as critical infrastructure with matching documentation, staffing and review depth; Telstra had no central or "golden" configuration record for the timing platform beyond the devices themselves; only two engineers had the relevant expertise, so there was no second opinion available; timing alarms sat outside the standard monitoring tools and were checked only during business hours; and the firmware fix for the rollover behaviour had existed for six years with no process to flag that it was never applied. The author separately argues for treating timing as an attack surface, since GNSS signals are weak, unauthenticated and can be spoofed or jammed, and for preferring documented point-to-point time links, the model Netnod itself runs, over peering arrangements that can silently reorganise themselves. The source gives no figure for how long the outage lasted, how many customers or how much money it cost, does not name the two engineers involved beyond noting their stand-down, does not give the TAP report's own publication date or a link to it, and does not identify the GPS receiver's vendor or firmware version.

Key facts

On 8 July 2026, Telstra's mobile network failed nationwide, disrupting calls, texts, calls to Australia's emergency number, trains, payment terminals, ticketing systems and EV chargers.
The cause: a GPS receiver in a Melbourne timing chassis, restarting after maintenance with never-updated firmware, defaulted to the wrong GPS epoch and set its clock 1,024 weeks (about 19.6 years) in the past, landing on November 2006.
A 2020 network redesign, without anyone reviewing its cumulative effect, cut Telstra's stratum-2 time sources from two to one per site and replaced a directional client/server model with self-organizing peering, removing both of NTP's built-in defenses against a bad time source.
In October 2025, engineers activated a previously unused GPS card in the Melbourne chassis to fix an unrelated fault, inadvertently promoting that server from stratum 3 to stratum 1, the network's top rank, with nothing left to contradict it.
The independent review, by Technology Audit Partners, found no documented "golden" configuration for Telstra's timing platform and no process that would have flagged a six-year-old unapplied firmware fix for the GPS rollover behaviour.

Why it matters

The outage is a case study in systemic risk that no single decision created. Two separate, individually defensible engineering choices, made five years apart by different people for different reasons, quietly removed both of NTP's independent defenses against a bad time source. Neither change was reviewed for its effect on the other, and the resulting architecture worked perfectly, and looked healthy, for years before a routine restart exposed it. GPS week-number rollover is also a known, recurring hazard, not a novel one: it has already hit twice, in 1999 and 2019, and any device that gets power-cycled with unpatched firmware can reproduce this failure regardless of industry.

Who it affects

Directly: customers of Telstra, Australia's largest mobile network, who lost voice calls, text messages and access to the national emergency number, plus the trains, payment terminals, ticketing systems and EV chargers whose infrastructure depends on the same network. More broadly, the lessons are aimed at any operator of a hierarchical time-distribution system, since the report's authors frame the failure mode as generic to critical services that assume synchronized clocks, not specific to telecoms.

How to use it

TAP's takeaways, as relayed in the post, translate into a checklist: classify timing as critical infrastructure with matching documentation, staffing and monitoring, not as an afterthought; keep a central, version-controlled "golden" configuration for every class of timing device and check deployments against it automatically; build redundancy in expertise, not just hardware, since Telstra had only two engineers who understood the setup; wire timing alarms into standard 24x7 monitoring with clear severities and owners, not business-hours-only review; apply vendor firmware updates and bulletins on a schedule rather than waiting for an incident; and prefer dedicated, documented point-to-point time links over self-organizing peering, since peering topology can silently rearrange itself into a shape nobody approved.

How solid is it

The account rests on an independent review that Telstra itself commissioned from Technology Audit Partners and chose to publish, which the author treats as commendable and credits with unusually candid findings. The retelling comes secondhand, through a blog post by Netnod, a national time-distribution operator with direct technical standing on the subject but also a stated preference for its own point-to-point model over the peering approach that failed at Telstra, an angle worth weighing. The post gives no link to the TAP report itself, no report publication date, and no numbers on outage duration, affected customer count or cost, so none of the narrative can be checked against the underlying document.

Risks and caveats

The piece does not say how long the 8 July 2026 outage lasted, how many customers or calls were affected, or what it cost. It does not name the two engineers who made the October 2025 change or detail their stand-down beyond the fact of it. It does not identify the GPS receiver's vendor or firmware version, nor does it mention any regulatory or government response to the outage. The author's explanation for why Telstra switched from client/server mode to peering in 2020 is explicitly flagged as a guess, not a finding stated in the TAP report itself.

“The protocol worked. The architecture did not.”

— Sven-Christian Ebenhag, Netnod