A single power event in one London zone took down banks, so test your zone failure

What happened

On 20 October 2026, Google Cloud's London region, europe-west2, suffered a multi-service outage. Google's incident report says it began at 23:08 Pacific time on 19 October, which is 06:08 UTC on 20 October. The cause, in Google's words, was that "a power event caused an outage within europe-west2-b zone". Elevated errors and intermittent network failures were also reported across the wider region.

The status page lists about 50 products as affected, including Compute Engine, Google Kubernetes Engine, Cloud Storage, Cloud SQL, Cloud Run, BigQuery, Spanner, Pub/Sub, Persistent Disk and VPC. The Register reports that the outage affected customers it names as Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix and Revolut, and that Dr Amro Al-Said Ahmad of Keele University estimated 38 services were down. It describes the outage as lasting about eight hours.

The timeline from Google's report, converted to UTC:

Google says customers could migrate workloads to another zone or region where feasible, those still affected should open a support case, and that it will publish a full analysis later.

Why it matters

A zone is the unit most estates are built around, and this was one zone. The failure started in europe-west2-b, one zone of the region. Yet the impact reached a long list of services and well-known organisations. Either those organisations were running in the affected zone only, or their failover did not work as designed. We cannot tell which from the public record, and it is the question to ask of your own estate.

Recovery took longer than the headline fix. The power event was reported mitigated at 11:12 UTC, but most workloads had recovered more than an hour later, and Google reported that creating new workloads was impossible for a time. If your recovery plan depends on starting new instances in the affected zone, it was not available when it was needed.

Provider status is not your service status. Google reported most customers mitigated at 14:03 UTC. For a customer, the outage lasts until their own checks pass, including data consistency, queued work and downstream systems.

Resilience is a property you test. Dr Ahmad argues, as quoted by The Register, that single-region failures can cascade through dependent applications and SaaS products, and that resilience needs multi-region deployments, workload portability and tested disaster recovery. We would add that the last of those is the one most often skipped.

What we would do

1. List the services that would stop if one zone failed. For each, record where its compute, storage, database and network paths live. Include the SaaS products you depend on, because they have their own zone dependencies.
2. Set a recovery target per service. Agree how long each service may be down and how much data it may lose, with the business owner. Some will need to survive a zone loss without human action. Others can wait hours.
3. Run a zone-failure exercise. Take one zone out of a non-production copy of an important service, or use your provider's fault-injection tooling, and time the recovery. Record what you assumed that was untrue.
4. Remove the dependency on starting new capacity in the failed zone. Keep enough running capacity in surviving zones, and check that deployment and scaling tools work without the affected zone.
5. Decide on multi-region deliberately. Cost it for the two or three services where an eight-hour outage would be most expensive, and choose per service. Do not apply it everywhere.
6. Read the post-incident analysis when it lands. Compare Google's account with your own timeline, and change your runbooks and contracts to match what you learn.

The lesson of an incident like this is cheap to apply. Find out what happens to you when one zone goes away, before a power event finds out for you.