Google Cloud's London Power Event: The Zone Failover Nobody Built
On October 20, 2026, a power event inside a single availability zone of Google Cloud's London region knocked UK banks, a national courier, a property portal, and remote court hearings offline for hours. The region had two other healthy zones the whole time. Almost none of the affected customers were built to fail over to them.
Starting at 06:08 UTC on October 20, 2026, Google Cloud's europe-west2-b zone, one of three availability zones that make up the London region, began failing because of what Google later described as a power event inside the facility. By the time the incident eased around 14:03 UTC, the outage had rippled through online banking at Lloyds, Halifax, Bank of Scotland, and HSBC, disrupted Royal Mail and DPD delivery tracking, took down Rightmove listings, and reportedly interfered with remote hearing links used by UK courts. Revolut alone reported disruption affecting roughly 3.4 million customers in Ireland. Google's own postmortem traced the root cause to the power failure in a single zone, mitigated it, and restored most services within hours.
The region was never actually down
This is the detail that gets lost in outage headlines: europe-west2 is a three-zone region, and only one zone, europe-west2-b, had the power event. The other two zones kept running the entire time. Google Cloud, like AWS and Azure, sells multi-zone regions specifically so that a customer can run redundant infrastructure across zones and keep serving traffic when exactly this kind of localized failure happens. The architecture for surviving this outage already existed inside the product every affected company was paying for. What was missing was the customer-side work: replicated compute across zones, load balancers configured to route around an unhealthy zone automatically, and databases that do not pin a single zone as a silent point of failure.
Why "multi-region" conversations miss this failure mode
Most resilience planning inside engineering orgs jumps straight to the dramatic version of the question: what happens if an entire cloud region goes dark? That is a real risk, but it is also expensive to solve and rare in practice. The much more common failure, this one included, is a single zone inside a region that is otherwise fine. Zone-level redundancy is cheaper to build than region-level redundancy, has lower latency overhead, and would have covered this specific incident completely. Teams that skip straight to debating multi-region disaster recovery, and never finish zone-level failover inside their primary region, end up with an expensive plan for a rare event and no protection against the common one.
- Audit whether your compute, cache, and managed database tiers are actually spread across zones, or whether "multi-zone region" on paper means "zone A, with a cold standby nobody has tested."
- Test the failover, not just the architecture diagram. A load balancer configured to route around an unhealthy zone is only real if someone has watched it do that under load, not just read the config.
- Treat stateful services as the hard part. Compute fails over easily. Databases and queues pinned to one zone for consistency reasons are usually the actual blocker, and they need a deliberate decision, not a default.
- Separate the zone-failover project from the region-failover project. They solve different problems, at different costs, for different probabilities, and bundling them into one "disaster recovery" initiative is how zone-level coverage quietly never ships.
The fix for this outage was already sitting inside the product. Almost nobody had built the switch to use it.
What this means if you are building or re-platforming a SaaS product
For teams building a product from scratch, this is the cheapest moment to get zone-level redundancy right, because it is a design decision, not a migration. A SaaS development engagement that treats zone failover as a day-one requirement, not a hardening task scheduled for after launch, avoids the far more expensive version of this problem: retrofitting failover into a production system with live customer data and an SLA already in effect. The companies hit hardest on October 20 were not using exotic infrastructure. They were using exactly the kind of managed cloud region most SaaS products run on, and they had simply never finished the part of the setup that would have made this a non-event.
A single-zone power failure is not an exotic black-swan incident. It is infrastructure doing what infrastructure occasionally does. The lesson from London is not "distrust Google Cloud." It is that the redundancy you are paying for only protects you if someone actually wires it up before the zone that fails is the one holding your only copy of the data.