Telstra's 8 July 2026 mobile outage began when a GPS card in a Melbourne timing chassis restarted and counted 1,024 weeks back, to 22 November 2006. The external review shows how a timing loop made that one wrong clock the network's majority, and why setting the clock right did not end the outage.
At 2:50am on 8 July 2026, engineers in Melbourne finished a planned change to a timing chassis, one of the boxes that tell Telstra's mobile network what time it is. When the chassis came back up, its GPS card "reset and used the previous epoch to calculate a date 1024 weeks in the past (November 2006)," according to the external review Telstra published in September. By about 4am the mobile core was failing. At its peak, Telstra's chief executive Vicki Brady told a Senate inquiry, the problem "impacted approximately 45% of all calls and data sessions on our mobile network."
The review gives the month. The day is arithmetic: 1,024 weeks before Wednesday, 8 July 2026 is Wednesday, 22 November 2006.
The press version of this story is an old box, a skipped patch and an undocumented change. All three are in the record. The review, written by Technology Audit Partners (TAP) and dated 24 August 2026, also shows how one card's wrong answer became the network's answer, and why setting the clock right did not end the outage.
TAP's report runs ten pages. Its timeline:
Telstra and its reviewer measure the recovery differently. Brady's statement to the Senate says that "By 10:00am, most calls and data services were working correctly, and by 4:00pm the initial issue we identified had been addressed." TAP says that "By 12:12pm on July 8th 2026 the majority of postpaid customer services were restored," and that residual issues ran "through July 11th 2026" (p.4). One is about calls and data across the network, the other about postpaid customer services.
On Triple Zero, Brady's statement, with a footnote updated on 2 September, says "59,321 calls to Triple Zero successfully connected and 611 experienced the error," and that Telstra completed 611 welfare checks.
GPS satellites broadcast the week number in a 10-bit field, which counts from 0 to 1,023 and then starts again. Every 1,024 weeks, about 19.6 years, the count wraps. A receiver has to decide which run of 1,024 weeks it is in, and many settle that with a window fixed in their firmware. When the real date passes the end of the window, the receiver lands 1,024 weeks in the past. The count itself wrapped in August 1999 and April 2019, as TAP notes (p.10); the next wrap is in November 2038.
A receiver's own window can close on any date its maker chose. On 6 September 2022, Chronos Technology, a UK timing-equipment supplier, listed products that "will experience a GPS rollover on the 18th of September 2022, causing the date on the unit to jump backwards by approximately 19 years," unless their owners took the action it gave for each. One entry reads "SSU 2000. Some GPS card hardware revisions," with a request to contact Chronos for details. According to iTnews's report of Telstra's Senate evidence on 17 July, the unit in Melbourne was a Symmetricom SSU-2000.
Put the two together and the date falls out. A receiver whose window closed on 18 September 2022 reads every date as falling between 2 February 2003 and 18 September 2022. Asked for 8 July 2026, it answers 22 November 2006, which is the date the network got. That is consistent with Telstra's card being one of the affected revisions; it does not prove it. Telstra has not said which revision it had, and Chronos says only "some."
If it was one of them, the card had been past its rollover for about three years, 1,109 days, by October 2025, when engineers made it Melbourne's source of time (p.3). TAP puts the trigger at the restart: "upon power up, the GPS card, without the critical firmware update installed, reset and used the previous epoch" (p.10). On our reading, a card in that state could keep the right date while it ran and lose it when it restarted.
Telstra had been told. According to iTnews's account of the Senate hearing, reminders about the update came in 2020 and 2022, and Brady said the teams "did consider" it, but "this update was affecting a feature that we were not using at that time."
That was true when it was said. In 2020 the replacement chassis gained a GPS card that was "never configured for automatic failover" (p.3). In October 2025 "the GPS card was activated and connected to the stratum 3 NTP server in Melbourne," which made Melbourne "a stratum 1 NTP source, effectively the same level as the NMI stratum 1 sources," the national measurement references the network was built around (p.3). TAP adds that "a 'Network at Risk' ticket should have been raised ... but this did not happen" (p.4).
So the feature came into use, and the decision not to patch was never re-made with that fact in hand. A decision keyed to whether a feature is in use expires when someone starts using it. A skip is a decision about a configuration, and it has to be filed against the configuration, so that changing one brings the other back up.
The record is less clear about the most recent warning. iTnews reported on 2 September that "The most recent warning that Telstra could have heeded was issued in January 2026." Hackaday, citing Telstra's Senate submission, wrote on 27 August that "A decision not to fix the bug had been taken as recently as January 2026, because the undocumented change to have the server rely on GPS time was unknown, and thus the update was considered unnecessary." If Hackaday read the submission correctly, the old decision was not just left standing: it was made again in January 2026, three months after the change it should have caught, by people who did not know the change had happened. We could not open the submission to check which account it supports.
Telstra's time network was built on three national references. In 2010 three stratum 1 sources from Australia's National Measurement Institute fed two stratum 2 servers, in Sydney and Melbourne, which fed three stratum 3 servers, in a "Client-Server configuration with peering only allowed across the same stratum levels" (p.3).
The 2020 replacement changed that shape. In the new chassis "a stratum 2 NTP server could not provide time to a stratum 3 NTP server in the same chassis," and the servers moved from "client/server to peering." With that came "the unknown introduction of looping" (p.3). TAP adds: "We have no evidence that the personnel involved ... were aware of or investigated this risk" (p.3).
On 8 July the loop did the rest. In TAP's words, "due to looping, all of the available NTP time sources began to agree that the date was 2006 and when the majority of available time sources agreed that the date was 2006, the clients - the network nodes and applications - accepted the incorrect date" (p.4).
That is the Network Time Protocol's selection rule working as designed. RFC 5905, the protocol's specification, picks "a majority clique of presumed correct candidates (truechimers) based on agreement principles" (p.41), using "Byzantine agreement principles originally proposed by Marzullo" (p.43). A majority vote protects a network from a minority of wrong clocks. It cannot protect it from one wrong clock whose answer the voters have been repeating to each other. TAP's own definition of the hazard: "A timing loop is when sources that appear independent are in fact validating one another - directly, or by tracing back to a common reference" (p.9).
The loop showed nine months before the outage. In October 2025 an incident report "noted that the Melbourne NTP had become a stratum 5 source" (p.3), but "the personnel involved did not recognize the meaning of Melbourne NTP at stratum 5" (p.4). NTP alarms "were checked during business hours in the element management systems by a limited number of individuals" (p.8). The protocol has a loop check of its own, the reference ID, which above stratum 1 "can be used to detect timing loops" (RFC 5905, p.22). It compares a server with its immediate source, so on our reading a loop that runs through intermediaries need not show up in it. We do not know what Telstra's servers logged.
When the clock was put right, the network was not. The wrong date had been written into records. TAP: "information for approximately 30,000 IP address prefixes were incrementally corrupted (written with the wrong date) by the Diameter Signalling Controller (DSC) in such a way that access attempts using those addresses were blocked from using the network regardless of available capacity" (p.5).
A clock can be set right in one step. Data stamped by a wrong clock has to be found and repaired, and "a variety of residual issues continued to be investigated and resolved through July 11th 2026" (p.4), three days after the time was right.
Brady's statement to the Senate, dated 17 July, says twice that the procedure was followed: "The team followed the relevant procedure," and "The team carrying out the maintenance work followed the correct procedures." On 2 September, the day TAP's findings were published, its footnotes were updated. Footnote 2 moved the start of the outage from "3:38am" to 2:50am, "when the Exhibition Street Synchronisation Unit ... was brought back online and began progressively supplying incorrect timing information." Hackaday's account of 27 August still gives 3:38 AM, the earlier figure.
TAP's findings are about the procedure itself. There were "no prechecks," and there was "inadequate technical review of the MOP (Method of Procedure) and localized approval – this despite the fact that the change was categorized as level 5 (the highest risk level)" (p.7). It found that "the MOP that was chosen was insufficient," and that once the change was complete it "was not tested to confirm that the key function of the chassis was working correctly (i.e., serving the correct time)" (p.7). By the time the effect of the change was known, "the two primary NTP engineers who were involved in the planned change on the chassis were on mandatory standdown" (p.8).
Both statements can be true at once: the team followed the procedure, and the procedure was the defect.
The protocol has a guard against a jump of this size. RFC 5905 says an offset "greater than the panic threshold PANICT (1000 s) ... SHOULD cause the program to exit with a diagnostic message to the system log" (pp.45-46), and the reference code's comment on such an offset reads "The offset is too large and probably bogus" (p.96). Telstra's step was 1,024 weeks, or 619,315,200 seconds: 619,315 times the threshold.
TAP's report does not say which NTP clients the network elements ran, or whether any of them had that guard switched on. Its finding of "No end-to-end architecture for mobile core timing, including client design and behaviour" (p.5) is where the answer would sit. Many embedded devices run simpler clients of their own, but we have nothing specific about Telstra's. The question for any network that takes its time from NTP is the one the report does not answer: if a source moves the date back nineteen years, what does each client do?
Show your work. gps_rollover_c10752.py does the week arithmetic with Python's standard library alone:
We compared, word for word, the two copies of TAP's report that Telstra has hosted at different addresses; the one not linked here now returns HTTP 404. They differ in 20 places, all of them heading numbers or text-extraction artifacts; no wording changed. Page numbers here follow the report's own "N of 10".
Not found or not read.
Chain of Consciousness keeps a dated, tamper-evident record in hash-linked entries. Log why a patch was skipped beside the configuration that made skipping safe, and the reason is on the record when someone changes that configuration.
pip install chain-of-consciousness npm install chain-of-consciousness
Or start without installing anything: Hosted Chain of Consciousness.