Google Cloud's backup generators failed to engage when mains power cut out at a London data center on October 20, 2026, and the resulting outage in a single availability zone reached far beyond that zone's own customers. Revolut, Lloyds, HSBC, Royal Mail, and England and Wales's court video system all went down for hours, and the UK's financial regulators are now being asked in Parliament how much of the country's banking infrastructure sits behind one cloud region.
Jump to what we checked in our own redundancy claims if your own architecture assumes a zone failure stays contained to that zone.
What Happened in Google's London Region
The outage began at 06:08 UTC when the europe-west2-b zone, one of three availability zones in Google's only UK region, lost power at what Google later described as a third-party facility. According to an internal engineering update reported by Computer Weekly, mains power returned relatively quickly, but the site's backup generators failed to engage. That forced Google's engineers to keep a frontend and backend traffic drain on the zone while onsite technicians manually verified backup power was actually working.
Google's status page listed 38 distinct products affected, including Compute Engine, Google Kubernetes Engine, Cloud SQL, BigQuery, and Cloud Run. The company's own incident record shows the first public acknowledgment at 08:35 UTC with no workaround offered, a workaround added at 10:24 UTC advising customers to migrate workloads to another zone or region if they could, and the cause named around 12:12 UTC. Most customers were back by roughly 14:00 UTC, nearly eight hours after the power event began.
Why a Single Zone Outage Reached a Whole Region
Google's own architecture promises that regional services run across all three zones in a region specifically so that losing one zone costs capacity, not availability. That promise is why Compute Engine VMs and zonal disks pinned to europe-west2-b went down with no workaround, while regional services were supposed to keep running on the two healthy zones.
They mostly didn't. Google's status updates describe services across the broader europe-west2 region, not just the b zone, experiencing elevated errors and intermittent failures throughout the morning. Google has not yet explained why its two unaffected zones didn't fully absorb the load that the failed zone would normally have carried, and that gap is the detail its promised incident analysis will need to answer.
What We Checked in Our Own Redundancy Claims
We reviewed every place at Krova Cloud where we tell customers a service is "regionally redundant" and checked whether we had actually tested a full zone failure against it, rather than just designing for one. We found one internal monitoring service that was architecturally spread across zones but had never been through a real failover drill. We scheduled one for the following week, since a redundancy design nobody has tested is a hypothesis, not a guarantee.
What to Check in Your Own Cloud Architecture
- If a vendor tells you a service is "regional" or "multi-zone," ask whether that claim has been tested against an actual single-zone failure, not just designed for one, since Google's own regional services didn't fully absorb this zone's load.
- Identify every workload you run pinned to a single zone, since Google's own workaround for this incident, migrate to another zone or region, only works for architectures built to support it in advance.
- Check whether your incident communications depend on the same cloud region you're reporting an outage about, a common and easy-to-miss single point of failure.
- Ask your downstream vendors, banking apps, courts systems, and logistics platforms among them this time, which cloud region and zone each of their critical paths actually runs in, since the blast radius of this outage reached well past Google's own customer list.
The limitation worth stating plainly is that Google has not yet published the technical analysis it promised, so the exact reason regional services degraded alongside the failed zone is still unconfirmed.
The verdict doesn't need that analysis to land, though: a backup generator failing to engage at one facility was enough to disrupt banking, courts, and parcel delivery across an entire country, and the zone-isolation guarantee did not hold as cleanly as the architecture promises it should.
The Rule
A multi-zone design only protects you from a single-zone failure if the other zones can actually absorb that zone's load when it happens, not just in the architecture diagram. If you've never tested your own "regional" service against a real zone outage, you don't know whether you have that protection, you're just hoping the backup generator engages when the lights go out.
Frequently Asked Questions
What caused the Google Cloud outage on October 20, 2026?
A power event at a third-party facility hosting Google's europe-west2-b availability zone in London. Mains power returned, but backup generators failed to engage, requiring manual verification by onsite technicians before services could be restored.
Which services and companies were affected?
Google listed 38 affected products including Compute Engine, GKE, Cloud SQL, BigQuery, and Cloud Run. Downstream, Revolut, Lloyds, HSBC, Royal Mail, DPD, Rightmove, and England and Wales's court video hearing system all reported disruption.
How long did the outage last?
The incident began at 06:08 UTC and Google reported most services mitigated by roughly 14:00 UTC the same day, nearly eight hours later, though some customers reported longer recovery times.
Why did a single zone failure affect the whole region?
Google's regional services are designed to run across all three zones in europe-west2 so a single zone's loss doesn't cause a regional outage. Google has not yet explained why the two unaffected zones didn't fully absorb the failed zone's load during this incident.
I'm Rohit, founder of Krova Cloud: disposable VMs with redundancy claims we've actually drilled, not just diagrammed. More debugging stories at debugly.dev.
![[Boost]](https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F9bnpwp59f3qnt0co2y5o.png)
