Google's London Outage Shows Why Backup Power Is the Dependency Nobody Load-Tests

The incident ran from roughly 06:00 to 12:10 UTC in the europe-west2-b zone. An external underground cable carrying power to feeder A broke at the exact moment feeder B was already unavailable for corrective repairs, following issues found during a routine quarterly generator load test on October 14. With both utility feeds de-energized, the facility's automation logic should have fired the emergency generator plant. It didn't. According to Google's report, the programmable logic controllers read a healthy utility source that didn't actually exist, and never issued the start command. UPS batteries carried the load until they ran out, and then the zone went dark. Thirty-nine Google Cloud products and two Google Workspace services were affected, with VMware Engine, Bare Metal Solution, and NetApp Volumes workloads interrupted for close to 15 hours in the worst-hit cases.

The Failure Wasn't the Power Cut — It Was the Control Logic

Data centers lose utility power regularly; that's precisely why generator plants and UPS systems exist. What makes this incident worth reading past the headline is where the chain actually broke. It wasn't a generator that failed to run — it was a control system that failed to recognize it needed to. A quarterly load test a week earlier had already flagged a problem serious enough to pull a circuit breaker for repair, and that maintenance state is exactly the condition the PLC logic misjudged when the real failure hit. Two independent weaknesses — a physical cable fault and a software/control misread — had to align for the outage to happen, and they did.

• Maintenance state blind spots. A system in a known degraded state (feeder B already open for repairs) needs different failure-detection logic than a system in full redundancy. Google's automation treated them the same.
• Single zone, broad blast radius. 41 products going down from one zone's power event means the dependency on that zone was wider than most customers assumed when they picked a region.
• Detection lag compounds duration. The gap between "generators should have started" and "someone notices they didn't" is the difference between a 10-minute blip and a 6-hour regional outage.

Redundant infrastructure only protects you if the system that's supposed to trigger it actually fires — and that's the one component most teams never get to test themselves.

What This Means If Your Stack Lives in One Region

Lloyds, HSBC, Royal Mail, and Revolut all felt this outage, and none of them chose to build on a single point of failure on purpose — it's simply where "available zone" and "acceptable cost" intersected when the architecture was designed. That trade-off is reasonable until a cloud provider's own backup system fails in a way its SLA never accounted for. For engineering teams evaluating whether to re-architect for multi-zone or multi-region resilience, the honest framing from this incident is that the provider's redundancy is not your redundancy. Google had generators. Google had UPS. Google still had a six-hour outage, because the layer that decides when to use backup power is itself a single point of failure if it's never exercised under real, unplanned conditions.

Building that resilience into your own application layer — health checks that fail over before a region visibly goes dark, data replication that doesn't assume one zone's uptime, deployment pipelines that can redirect traffic without a war room — is web development work most teams postpone until an outage forces the conversation. The cost of doing it proactively is a fraction of six hours of Lloyds-scale downtime.

Questions Worth Asking Your Own Infrastructure Team

• Do we know which of our critical paths depend on a single availability zone, and have we mapped that dependency recently?
• If our primary provider's backup power or failover logic doesn't trigger, how long until someone on our team notices — and what's our actual recovery path?
• When was the last time we tested a regional failover end-to-end, not just reviewed the runbook for one?

Frequently Asked Questions

What caused the Google Cloud London outage on October 20, 2026?

An underground cable carrying power to one feeder broke while a second feeder was already offline for repairs. The facility's control system misread the situation as having a healthy utility source and never issued a start command to the emergency generators, so UPS batteries drained and the zone lost power entirely.

How long did the outage last and what was affected?

The incident ran from about 06:00 to 12:10 UTC in the europe-west2-b zone, with 39 Google Cloud products and two Workspace services affected. VMware Engine, Bare Metal Solution, and NetApp Volumes customers saw disruptions lasting close to 15 hours in the hardest-hit cases. Lloyds, HSBC, Royal Mail, and Revolut were among the companies that reported impact.

Is this specific to Google Cloud, or does it apply to any provider?

The specific control-logic failure was Google's, but the structural lesson isn't provider-specific: any single zone's backup power and failover systems are themselves a dependency that can fail silently until a real event tests them. AWS and Azure have each had comparable single-region incidents in 2026.

What should engineering teams actually do about this?

Map which critical systems depend on a single zone or region, test failover under conditions that mimic a degraded (not just fully redundant) state, and build the application-level resilience — health checks, replication, traffic redirection — that doesn't assume the provider's backup layer will always fire correctly.

Six hours is a long time for a bank's customers to be locked out of their accounts over a generator that never got the memo. The infrastructure was there. The signal to use it wasn't — and that gap is exactly where most teams' own disaster-recovery plans have never actually been tested either.