Introduction
On October 20, 2026, at 07:08 London time, a power failure hit the europe-west2-b availability zone of Google Cloud. Eight hours later, when the all-clear was finally given, British banks, court clerks, delivery drivers and millions of end users had all experienced first-hand what it means to depend on a single availability zone within a hyperscaler. The outage laid bare a tension as old as cloud SLAs: the gap between the promise of redundant architecture and operational reality when an incident actually strikes.
When Zonal Redundancy Fails to Deliver
Google Cloud regions are structured around availability zones designed to operate independently. In theory, a failure in europe-west2-b should not drag down services running in London's two other zones. In practice, 38 cloud products experienced disruptions that morning — BigQuery, Cloud Run, Google Kubernetes Engine, App Engine and Cloud Filestore among them.
The root cause lay in the network architecture: the equipment responsible for routing outbound traffic to the internet was physically located within the zone that lost power. When those devices went offline, the routes advertised by Google were withdrawn from partner networks, making services unreachable well beyond the affected zone itself. This cascade failure was not unprecedented: in July 2022, the same europe-west2 region experienced a similar incident with comparable regional-scale consequences.
Google initially offered no workaround. The first public status communication came two and a half hours after disruptions began. Only after several hours was a formal recommendation issued: migrate workloads to an available zone. For applications not designed for that kind of failover, the guidance arrived too late.
An Entire Economy Concentrated in a Single Zone
What makes this incident particularly instructive is the breadth of services affected. Lloyds Banking Group, HSBC, Revolut, Royal Mail, Rightmove, DPD and BT were among the organisations impacted. The UK's judicial video-conferencing platform (HM Courts and Tribunals Service), used for remote hearings across England and Wales, also suffered outages.
The concentration of such diverse services — banking, justice, logistics, property, telecoms — on a shared cloud infrastructure raises a genuine governance question. What is remarkable here is not that a hyperscaler went down: they all do. What stands out is that organisations as different as a high-street bank, a national postal service and the court system shared a single point of failure, with business continuity plans that had evidently not accounted for this scenario.
What Cloud Architects Need to Revisit
Three lessons stand out.
Having a multi-zone architecture on paper is not enough. Failover between zones must be tested regularly, and DNS and network configuration must be verified to execute the switch within minutes. An incident is the wrong time to discover that a hidden dependency is anchoring an application to a single zone.
Vendor status monitoring must be integrated into internal observability tooling — not left to wait for official communications. Two and a half hours of uncertainty is diagnostic time lost and escalation decisions delayed.
Finally, for genuinely critical services, resilience extends beyond cloud architecture choices. It means questioning supplier concentration and seriously evaluating multi-cloud or hybrid architectures — even when the added complexity is hard to justify during normal operations. The next power cut will give as little warning as this one did.