The Auckland Power Crisis: When Nature Humbles Technology
Return to Part 0: Table of ContentsPrevious Article: Episode 6 — Forty-Seven Seconds of National Darkness
The phone rang at six in the morning on February 19, 1998.
I grabbed it half-asleep. The voice on the other end was not interested in pleasantries. "The power is down for the entire Auckland CBD. The entire country has no internet."
I was Technical Services Manager at ICONZ, New Zealand's first commercial ISP. We ran on Linux. We ran the email and DNS infrastructure for government departments that had come to depend on us as if we were essential infrastructure. Which, it turned out, we were. Three of Auckland's four power supply cables were already gone. The fourth was about to follow.
Coffee in hand, I was in the car within minutes.
What happened over the next few hours taught me more about resilience architecture than any certification has managed since. It confirmed something I already suspected: Linux could survive almost anything you threw at it. Keeping it running when the physical world collapsed was a different problem entirely.
Auckland's Infrastructure Nightmare
To understand what we were facing that February morning, you need to understand the particular vulnerability of Auckland's CBD power supply.
Mercury Energy supplied the entire central business district through four 110 kV underground cables. Four cables for New Zealand's largest city, its commercial heart, its banks, its government offices.[1] This was not a hidden flaw. Mercury's own engineers had flagged the cables' condition for years. A consultant's report in 1993 recommended replacement. The cables were not replaced.
The company, following the electricity sector reforms of 1992, had reduced its engineering workforce from around 1,400 to approximately 600 staff.[2] The institutional knowledge of how much load those cables could actually tolerate walked out the door with the redundancies. What remained was a maintenance regime that trusted historical performance rather than actual condition assessment.
February 1998 was Auckland's hottest month on record at the time. Air conditioning loads were unprecedented. Cables that should have been running well below rated capacity were at full load in ground made thermally resistant by months of drought.[3] The first cable had failed in January. The second on February 9. By February 19, three of the four had gone. The entire CBD was surviving on one remaining cable.
My phone rang that morning because the situation was critical, not yet catastrophic. Everyone could see what was coming. The fourth cable failed on February 20. What followed was five weeks without reliable power to Auckland's CBD: roughly 60,000 workers disrupted, estimated losses of hundreds of millions of New Zealand dollars, and an international media event that CNN covered with reports some overseas readers interpreted as New Zealand losing power entirely.[4]
ICONZ was sitting at the centre of this.
The First Commercial ISP
By 1998, ICONZ had been operational long enough to become genuinely important. We ran on Linux because the economics and flexibility of it were right for what we were doing. No commercial operating system gave a small team the control, the cost structure, and the technical depth to run national infrastructure.
Our production systems ran Red Hat. The kernel was in the 2.0 series; Linux 2.2, with its improved networking and SMP support, was still months from release. We were not waiting for it. What we had worked.
What made the situation acute on February 19 was not our software. It was the building. The server room had no generator. Commercial power from Mercury Energy, the same as everyone else in the CBD.
Most of New Zealand's government departments using email in 1998 were routing through us. When the CBD power situation became critical, they had no email, no internet. In 1998, that was not a minor inconvenience. For government operations, it was a genuine disruption.
The Whangarei Solution
I had a colleague who knew someone in Whangarei with a generator. Not a rack-mounted UPS. Not a managed diesel backup unit from a data centre supplier. A generator. In Whangarei, roughly 160 kilometres north of Auckland.
He got in his car and drove there.
While he was gone, we assessed what we had and what we needed to bring back online first. This is where the Linux architecture paid off in a way I had not anticipated before that morning. Our systems were modular. The configurations were text files. They were documented. We knew the startup sequence, the dependencies, the order of operations. When the generator arrived, there was no uncertainty about what to do next.
We cabled the server room. By lunchtime on February 19, ICONZ was operational.
We were ready before the fourth cable failed.
Every other ISP in Auckland was still down when February 20 arrived and the last major cable went. ICONZ was accepting calls, delivering internet services, government email flowing again. The only operational ISP in New Zealand, running on a diesel generator sourced from a personal contact in Whangarei.
Twenty-eight years later, that day still makes me laugh.
What Linux Had to Do With It
There is a question worth pausing on: what exactly did Linux contribute to this story?
The short answer is that Linux did not save us. Our colleague and his car did.
The longer answer is more interesting. Linux contributed in two ways that only became clear in retrospect.
First, operational clarity. Our systems ran on commodity hardware, configured in text files, managed by a small team who understood every layer of the stack. When power was restored, there was no complex relicensing procedure, no proprietary configuration locked inside a system we could not examine. We brought everything up the same way we always did, because we understood it completely. The knowledge was in our heads and in readable files, not locked in vendor documentation behind a support contract.
Second, the culture of the people who ran Linux systems in 1998. The colleague who drove to Whangarei was not following a runbook. There was no runbook for this. He was following a culture that said: the problem is in front of you, the resources available are what they are, go fix it. This is the same culture that produced the kernel itself. Distributed responsibility, bias toward action, no waiting for perfect conditions or permission from someone upstream.
Torvalds did not design Linux to survive the Auckland Power Crisis. But the philosophy embedded in how it was built, and in the community that chose to build their infrastructure on it, turned out to be exactly what the situation required.
The Lesson Mercury Energy Learned Too Late
The ministerial inquiry into the Auckland Power Crisis, released in mid-1998, identified what any engineer on the ground could have told them. Mercury Energy had known for five years that the cables were at risk. The institutional knowledge to manage that risk had been eliminated in the post-reform restructuring. A cost-saving decision that looked rational in a spreadsheet became catastrophic in practice.[5]
Every architecture review I have run in the thirty years since has produced at least one version of this problem. A dependency everyone knows about. Everyone has flagged it. Everyone keeps deferring it because replacement is expensive and the current system is still working.
This pattern is a board governance failure as much as an engineering one. In the Cyber Sunday series, the Audit of Intent framework asks boards whether they genuinely intend to address known risks or whether they intend to defer them indefinitely while claiming to have "prioritised" them. Mercury Energy's cables are the physical infrastructure version of an unpatched critical system. In both cases: a risk report received, a risk appetite accepted, and then reliance on historical performance until the system failed.
The cables worked until they did not. By the time they stopped, there was no recovery path that did not involve weeks of disruption and a government inquiry.
What I took away from February 19, 1998 was simpler than any framework: you cannot wait until the crisis to discover your single points of failure. By then, the only options are bad ones.
Modern Bridge: The Same Vulnerability, Larger Stakes
In 2026, the Auckland Power Crisis has a structural equivalent in cloud infrastructure.
On December 7, 2021, AWS us-east-1 experienced a significant outage that took down services for thousands of companies, including major consumer platforms. A network infrastructure failure triggered cascading failures across Amazon's internal tooling.[6] The underlying infrastructure failed. The services built on top of it had no recovery path that did not wait for AWS to resolve the problem.
The outage lasted hours, not five weeks. But the pattern was the same as Mercury Energy's cables. A critical dependency. A single failure domain. Insufficient redundancy for the actual risk profile.
New Zealand's NZISM and the Protective Security Requirements framework address this directly. They require agencies to assess critical dependencies and implement resilience measures proportionate to risk. In practice: multi-region deployment for critical workloads, backup connectivity independent of primary providers, and recovery time objectives tested against real failure scenarios, not assumed ones.[7] The frameworks exist. The question is always whether the investment was made before the outage or after.
The cloud-native community has a name for what my colleague did when he drove to Whangarei. They call it chaos engineering: deliberately inducing failure to verify that recovery paths actually work, before the production incident forces the test. Netflix's Chaos Monkey, which randomly terminates production instances to verify system resilience, is the canonical version. The principle is the same. Find your single points of failure before a crisis does.
This is also the central argument running through the Zero Trust Architecture series. Architectural debt accumulates through deferred decisions: a single failure domain, a single vendor dependency with no tested fallback, a recovery path that exists on paper but has never been run. The architecture review that flags a dependency but defers remediation is making the same calculation Mercury Energy made when it chose not to replace the cables.
In 1998, we improvised a recovery path that had not been designed into the system. In 2026, the tools exist to design those paths in advance, test them deliberately, and govern them through frameworks with real teeth. The barriers are not technical. They are organisational: the same decision Mercury Energy made when it chose not to replace the cables.
The Auckland Power Crisis cost Mercury Energy an estimated NZ$150 million in direct costs, plus the reputational damage of a government inquiry and a CEO who died at his desk two days before the report was released.[8] The proactive replacement would have cost a fraction of that.
Resilience is not a feature you add after the crisis. It is an architectural decision you make before it.
What outage or infrastructure failure taught you the most about resilience, and what role did the human element play in the recovery? I am interested in both dimensions.
Next week in Episode 8: Red Hat goes public at $14 per share on August 11, 1999 and closes at $52.06. IBM watches the market speak. The biggest open-source bet in history is about to be placed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
- Wikipedia: 1998 Auckland power crisis. https://en.wikipedia.org/wiki/1998_Auckland_power_crisis. Corroborated by NZ Herald and RNZ reporting.
- Wikipedia: 1998 Auckland power crisis (workforce figures). Corroborated by multiple secondary sources. Primary: Report of the Ministerial Inquiry into the Auckland Power Supply Failure (1998).
- RNZ: "The night the lights went out in Auckland." 2018 retrospective. https://www.rnz.co.nz/national/programmes/eyewitness/audio/2018636891/the-night-the-lights-went-out-in-auckland
- Wikipedia: 1998 Auckland power crisis (economic impact). Loss figures range $128M–$300M+ across sources. Conservative "hundreds of millions" framing used per handoff Flag 2. Primary: Report of the Ministerial Inquiry.
- Report of the Ministerial Inquiry into the Auckland Power Supply Failure. New Zealand Government, 1998.
- AWS us-east-1 outage, December 7, 2021. Widely reported. AWS Service Health Dashboard. Causation simplified per handoff Flag 4: network infrastructure failure triggered cascading outages.
- New Zealand Information Security Manual (NZISM). https://nzism.gcsb.govt.nz. Protective Security Requirements (PSR). https://www.protectivesecurity.govt.nz. Described as resilience frameworks requiring dependency assessment proportionate to risk.
- Mercury Energy direct costs approximately NZ$150 million (historical secondary sources including University of Auckland contemporaneous analysis, 1998). CEO Wayne Gilbert: confirmed in RNZ retrospective. Referenced with appropriate sensitivity.