AW Dev Rethought Flash: One Zone Failed. Two Zones Watched. Google Has No Answer.

At 06:08 UTC on October 20, mains power failed at a third-party facility in London hosting europe-west2-b — one of three availability zones in Google Cloud’s UK region. Power came back relatively quickly. What didn’t come back was the backup generators. They failed to engage. Onsite engineers had to manually verify power before Google could restore the zone.

By the time services recovered, nearly eight hours had passed. Revolut, Lloyds, HSBC, Royal Mail, DPD, Rightmove, and England and Wales’s court video hearing system had all reported disruption. Over 70 million Revolut users were locked out of their accounts. UK Parliament began asking regulators how much of the country’s banking infrastructure depends on a single cloud region.

The outage itself is a story. The part Google hasn’t answered yet is a bigger one.

What Actually Went Down

Google’s status page listed 38 products affected — Compute Engine, Google Kubernetes Engine, Cloud SQL, BigQuery, Cloud Run, and more. Any virtual machine or zonal disk pinned to europe-west2-b had no workaround. They were simply down.

The timeline tells you how unprepared the response was:

• 06:08 — Power event begins
• 08:35 — First public acknowledgment, no workaround available
• 10:24 — Workaround issued: move workloads to another zone or region if possible
• 12:12 — Cause identified
• ~14:00 — Most customers recovered

Two and a half hours between the start of the incident and the first public acknowledgment. Another two hours before customers were even told to move their workloads. For a cloud provider running banking infrastructure, that timeline is hard to defend.

The Question Google Hasn’t Answered

Here’s where it gets architecturally uncomfortable.

Google Cloud’s London region — europe-west2 — has three availability zones. The entire design premise of a multi-zone region is that one zone failing does not take down the region. Traffic should shift. Services should degrade gracefully. The other two zones should absorb the load.

They didn’t.

Services across the wider europe-west2 region saw elevated errors and intermittent failures throughout the morning — not just in the failed zone. Google has not explained why. The promised technical post-mortem hasn’t been published. The cause of the regional degradation, not just the zone failure, remains unconfirmed.

This matters because multi-zone redundancy is the architectural promise that enterprises buy into when they choose a cloud region. If a single zone failure can degrade the entire region, that promise has a condition that wasn’t in the brochure.

The Deeper Problem: One Region, One Country

The UK parliamentary questions aren’t just political noise. They point to a real structural issue.

Google Cloud has one region in the UK — europe-west2 in London. There is no europe-west2 equivalent in Manchester or Edinburgh to fail over to while staying within UK data residency requirements. For organisations bound by UK data sovereignty rules — which includes a significant portion of British financial services — failover to another Google Cloud region means leaving the country. That’s not always an option.

A three-zone region only protects you from a zone failure. It doesn’t protect you from a region failure — and when your cloud provider has one region in your country, those two things become the same problem.

Revolut serves 70 million users globally. Its UK banking licence requires data to stay in the UK. When europe-west2 degraded, there was nowhere domestic to go.

What This Means for How You Build

The Google London outage isn’t an argument against cloud infrastructure. It’s an argument against treating availability zone redundancy as a substitute for thinking about regional single points of failure.

If your application runs in a single cloud region — any cloud, any provider — and that region goes down, your redundancy within it is irrelevant. Multi-zone helps you survive zone failures. It does not help you survive what happened on October 20.

For teams building on Google Cloud UK specifically:

• Any workload that cannot tolerate UK-region failure needs either a multi-region architecture or a documented recovery plan that accepts the downtime
• Zonal services like Cloud SQL and zonal Persistent Disks have no automatic failover — they require explicit design for resilience
• Managed services like Cloud Run and GKE Autopilot handled the failure better than zonal resources, but still showed elevated errors during regional degradation

The backup generator failure is a facilities problem. The zone isolation failure is an architecture problem. The single-region dependency is a strategy problem. They all landed on the same morning.

Final Thought

Google will publish a post-mortem. The generators will be fixed. The zone will come back online hardened. That’s the predictable end of this story.

The unpredictable part is the question it leaves open for every organisation running critical infrastructure on a single cloud region: not if this happens to you, but when — and whether you’ve designed for it or just assumed the redundancy guarantees would hold.

They didn’t hold on October 20. That’s worth building around.