A second location is a recovery plan only when it can carry the load and reach everything it needs.
What happened
On 20 October 2026, power failed in Google Cloud’s London zone europe-west2-b. One supply was isolated for maintenance; when the other failed, faulty generator control logic prevented automatic startup. UPS batteries ran out.
Failover then overloaded capacity in neighboring zones. Shared control-plane requests to the failed zone also timed out, spreading errors beyond the original power failure. Google’s 4 November report puts the main impact at 6 hours and 8 minutes, from 07:00 to 13:08 BST. Some workloads recovered later.
The boundary
Power loss was confined to one zone, not all of London or Google Cloud. Regional impact varied. Cloud SQL HA instances without the affected regional-disk failure completed failover. Google reports correcting the generator controls and testing load transfers, with further resilience work planned.
Owning hardware does not remove electrical faults, capacity limits or flawed recovery automation. This case supports testing those assumptions wherever the workload runs.
The point
Count usable recovery capacity and independent dependencies, not just locations.
Before calling a workload resilient, test these questions:
- Can the remaining nodes carry peak demand after losing the largest zone?
- Can recovery proceed without APIs, storage or metadata in that zone?
- Does the drill verify application reads and writes, rather than node health alone?
Use the exit-readiness checklist to turn those answers into an exercised recovery plan. The sizing example below is a starting point for comparison, not a substitute for a failure-domain design.
Sources
More incident dossiers
- A cloud told 495 customers: restore from your own backups — IDC Frontier (IDCF Cloud)
- Two gateways. One shared way to fail. — Microsoft Azure
- One failed AI request became 48 more — Microsoft Azure
- One suspended account cut off three clouds — Google Cloud / Railway
- Multi-AZ did not survive the region — AWS
- Cloudflare went down, too — Cloudflare
- Azure’s global front door closed — Microsoft Azure
- One empty DNS record reached across AWS — AWS
All cloud outage evidence → · Test your cloud exit readiness →