Introduction
On October 20, 2026, in the early hours of the morning, thousands of UK banking customers found their apps failing in rapid succession. Revolut stopped processing payments and ATM withdrawals. Lloyds and HSBC portals returned errors. English civil court video hearings were cut short. The cause was neither a software bug nor a cyberattack, it was a severed underground cable and two misconfigured programmable logic controllers.
When the Safety Net Fails
At 06:00 UTC, the external power supply to the datacenter hosting Google Cloud's europe-west2-b zone in London was cut following an underground cable failure. The scenario was accounted for in the datacenter's design: UPS systems were meant to bridge the gap while backup generators spun up automatically. They never did.
The post-incident report published on November 4 documents the root cause: both programmable logic controllers (PLCs), primary and backup, had a flaw in their voltage detection logic. Each PLC reported a healthy power source as available, even though both datacenter feeds were offline. The generators never received their start signal. The UPS batteries drained in five minutes. Servers, storage, and networking equipment went dark.
The full outage lasted seven hours and fifty-two minutes. More than fifty Google Cloud products were affected: Compute Engine, Cloud SQL, Cloud Storage, BigQuery, GKE, Cloud Run, the entire stack of a single zone.
Twelve Services, One Cascade
The shockwave did not stop at Google's perimeter. Twelve third-party services dependent on that zone went down in turn. Revolut lost connectivity, then transfers, then ATM withdrawals, in that order. Lloyds, HSBC, and Royal Mail were all impacted. Four hours after Google's official resolution, six of Revolut's twenty-seven services remained degraded.
What this incident exposes is the structural gap between logical resilience and physical resilience. Multi-zone architectures protect against application failures and software-level outages. They do not compensate for an engineering flaw in a datacenter's industrial control systems, systems that neither customers nor their auditors can directly inspect.
Critical Infrastructure: Designated, Then Down
The regulatory timeline adds a particularly instructive dimension. In July 2026, the UK Treasury formally designated Google Cloud EMEA Limited, alongside AWS, Microsoft Azure, and Oracle, as a "critical third party" to the UK financial system. A first in Europe, the designation acknowledged the systemic dependence of financial institutions on public cloud providers. Three months later, one of those newly regulated providers recorded the most high-profile outage of the year in the UK.
For organizations subject to DORA, the EU Digital Operational Resilience Act, in force since January 2025, this incident is a concrete proof of concept: business continuity testing must include failure scenarios at critical cloud providers, not just internal failures.
What IT Leaders Need to Take Away
Google has reprogrammed the faulty PLCs and committed to strengthening its physical infrastructure testing protocols. But those corrective actions do not answer the questions every CIO should be asking right now.
Do your continuity plans actually test a complete cloud zone outage lasting several hours, with a verified, working failover to an alternative region? Does your architecture assume a zone is available unless the provider declares an incident? That London datacenter lost power six minutes before Google detected its first application errors.
And for financial organizations: are your DORA-mandated resilience tests with critical third parties already scheduled and documented for 2027?
Cloud resilience is not written into the SLA, it is proven in the generator room.