Consultation

What this outage teaches · October 29, 2026 · 3 min

What this outage teaches — October 2026: one Google Cloud zone in London, about eight hours

A power event in one Google Cloud zone took services down for hours. What we know, what we do not know yet, and what to check on Monday.

When
Impact from about 06:08 UTC on 20 October 2026; “mitigated for most customers” at 14:03 UTC
Where
europe-west2-b, one of the three zones of the London region
Cause according to Google
“A power event caused an outage within europe-west2-b zone.”
Services named
BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, App Engine, NetApp Volumes, GKE, Managed Kafka (per The Register)
Not yet public
Google's incident analysis, promised once its internal investigation is complete

What we know

In the early hours of 20 October, a power event took a zone of Google Cloud's London region offline. Customer impact began around 06:08 UTC. At 11:58 UTC Google tentatively projected full recovery by 13:00 UTC, and at 14:03 UTC it described the issue as mitigated for most customers, with a very small number still affected. Roughly eight hours from first impact to “mostly fixed”.

Several well-known UK organizations were reported as affected, among them Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix and Revolut. Those reports come from the press and outage trackers. In the sources we read, none of those companies had confirmed it, and we do not know which of them depended on the affected zone.

What we do not know yet

  • The cause beyond “power event”: Google has promised an analysis once its internal investigation is complete.
  • Why the loss of one zone was visible to so many. Google speaks of one zone only; an academic quoted by The Register calls it “a regional outage centered on europe-west2”.
  • Whether the affected customers had multi-zone designs that failed to fail over, or single-zone designs.

What it teaches

A zone is supposed to be the unit you can lose. The useful question is not whether Google failed, but which of your services would have noticed.

  • Losing a zone is the failure cloud architecture promises to absorb, and the one most often untested. A service is multi-zone when it has actually failed over, not when the diagram says so.
  • Managed services hide their zone. Storage, queues and databases you did not place yourself may be single-zone by default. Check, don't assume.
  • Eight hours is a long time against an impact tolerance. If you wrote two hours for a payments service, a zone-level outage like this one exceeds it unless failover works.

Check on Monday morning

  1. List the services you run in a single zone, including managed ones you did not place yourself.
  2. Pick one and fail it over, stopwatch in hand. If you cannot, write down why.
  3. Check that your monitoring, status page and alerts do not live in the same zone or provider they watch.
  4. Compare eight hours with the impact tolerance you wrote down for your most important service.

Sources

Go further