Skip to main content
Change Risk Intel
Cloud & SaaS

Google Cloud europe-west2 Outage: What One Zone Failure Exposed

Ben Ennis Founder, Ennis Studio · former Partner Technology Advisor, ServiceNow · 12 min read

No affiliate links appear in this article. Incident facts come from Google’s own incident page and documentation, linked inline and in Sources. Google has not yet published its full analysis, so this piece sticks to what Google has stated. The section on UK rules summarizes published regulator guidance and is not compliance advice.

Table of contents

Why this matters

Cloud architecture reviews usually treat a zone as the smallest thing that can fail and a region as the thing that won’t. Google’s own documentation says zones are designed to minimize the risk of correlated failures “caused by physical infrastructure outages like power, cooling, or networking.” On October 20, a power event in one London zone took down services in that zone for hours. It also caused errors elsewhere in the region, and the BBC reported disruption at Revolut, Lloyds Bank, HSBC and the courts.

For change managers, the incident tests three assumptions most risk assessments make quietly: that “multi-zone” means “unaffected by a zone loss,” that failover capacity will be available when you need it, and that the provider’s public status page will tell you what’s going on in time to act. On October 20, each of those turned out to be only partly true.

What did Google say happened?

Google’s incident page gives the start as 23:08 US/Pacific on October 19 (06:08 UTC on October 20) and the end as 07:00 US/Pacific (14:00 UTC), a duration of 7 hours 52 minutes. It lists 38 affected products, from Compute Engine, Persistent Disk and GKE to Cloud SQL, Spanner, BigQuery, Pub/Sub, Cloud Run and VPC.

The page’s updates show how the picture changed:

  • First public update, 08:35 UTC. “Multiple Google Cloud services are experiencing elevated errors and intermittent network failures in europe-west2 region.” The suggested workaround at that point was “None for now.”
  • Cause named, 11:12 UTC. “Due to a power event we had suffered an outage within europe-west2-b zone. The power event is mitigated.” The symptoms changed to say services were “unavailable in europe-west2-b zone,” with some services in the wider region seeing “elevated errors and intermittent network issues.”
  • Recovery, 11:58 UTC. Google said it was “prioritizing the recovery of existing workloads” and that “customers may not be able to yet create new workloads.”
  • Most workloads back, 12:10 UTC. Google reported “recovery of services for most workloads in europe-west2.”
  • Final update, 14:03 UTC. The issue was “mitigated for most of the customers,” with “a very small number of customers” still affected. Google said it will publish an analysis once its internal investigation is complete.

From the 09:24 UTC update onward, the workaround text read: “If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region).”

Timeline of the Google Cloud europe-west2 incident on October 20, 2026, and the 38 affected products grouped by family

We grouped the 38 products by family. Databases and caches (10, including AlloyDB, Spanner, Cloud SQL, Bigtable, Firestore and five Memorystore variants) and data and integration services (10, including BigQuery, Dataflow, Dataproc, Pub/Sub and Managed Kafka) make up more than half the list. The rest are compute and containers (6), storage (5), networking (5) and two others. The grouping is ours. The product list is Google’s.

Why did a zone failure feel like a region failure?

Google’s infrastructure reliability guide draws the line clearly. Zonal resources, such as Compute Engine VMs, zonal persistent disks, single-zone GKE clusters, Dataflow jobs and Cloud SQL instances, “might” be affected by a failure in their zone. Regional resources, such as regional managed instance groups, regional Cloud Storage buckets, regional GKE clusters, VPC subnets, regional Spanner instances and Cloud Run services, “are resilient to incidents in a specific zone.”

Three things explain why customers on paper-resilient designs still had a bad morning.

The region saw errors too. Google’s own symptom text says “some services in europe-west2 region” had elevated errors and intermittent network issues, outside the failed zone. Regional services can only survive a zone loss if the surviving zones can absorb the load, and control-plane and networking services in the region have to keep working.

Failover often needs new capacity. Google’s regional MIG documentation says a regional group keeps serving from its remaining zones, but it won’t add instances to make up for the lost zone unless autoscaling is configured, and Google recommends overprovisioning. During this incident, Google warned customers “may not be able to yet create new workloads.” A failover plan that depends on launching fresh instances in the middle of an incident is the plan most likely to stall.

Many workloads are zonal without anyone deciding they should be. A standalone Cloud SQL instance, a single-zone GKE Standard cluster or a VM with a zonal disk is a zonal workload, whatever the application diagram says. The guide puts plain Cloud SQL instances and Compute Engine VMs on the zonal list.

Which architecture choices held up?

Google hasn’t published per-product impact yet, so we can’t say which customers stayed up. What we can do is compare the documented behavior of common configurations with what a zone loss does.

ConfigurationDocumented behavior in a zone outageWhat to check
Cloud SQL with HA”In the event of an instance or zone failure, the standby instance becomes the new primary” (Cloud SQL HA)Whether HA is actually on, and whether clients reconnect cleanly
Standalone Cloud SQLListed as a zonal resource (reliability guide)Restore time from backup into another zone
GKE regional cluster”If a single zone becomes unavailable, your control plane is not impacted” (GKE)Node capacity left in the surviving zones
GKE zonal Standard clusterSingle-zone clusters are zonal resourcesWhether you can rebuild elsewhere from code
Regional MIGKeeps serving from remaining zones; adds instances only with autoscaling (regional MIGs)Overprovisioning margin, autoscaler limits
VMs in multiple zones99.99% monthly uptime SLA in most regions, versus 99.9% for a single instance (Compute Engine SLA)Whether all tiers, not just the web tier, are spread out

Two points stand out. First, the SLA gap between one instance (99.9%) and instances spread across zones (99.99%) is Google pricing in exactly this kind of event. An outage of nearly eight hours is about 1.1% of a 30-day month, which is far beyond what either target allows. Second, GKE regional clusters can’t be converted back to zonal, and Autopilot clusters are always regional, according to the GKE documentation. Choosing regional at creation time is a design decision with a long tail, so it belongs in architecture review, not in a later change.

What should change boards do during a provider incident?

A provider incident is a change-risk event even when you haven’t changed anything. Our standing CAB agenda item for provider incidents covers the after-action review. During the event, three decisions matter.

Freeze non-urgent changes in the affected region. Deploying into a region that’s shedding errors makes troubleshooting harder and can turn a provider problem into your own. A freeze rule tied to an active provider incident is simple to write and easy to audit.

Pre-approve the failover change. Google’s workaround, moving workloads to another zone or region, is itself a change. If shifting traffic or promoting a replica needs a CAB meeting at 07:00 on a Tuesday, it’ll happen late. Make it a standard change with a tested runbook and named approvers, and test it the way our cross-region failover testing guide describes.

Don’t wait for the public status page. The first update on the public incident page is timestamped 08:35 UTC, 2 hours 27 minutes after Google’s stated start. Google’s fallback documentation says the public dashboard covers “broad, severe” incidents, while “Personalized Service Health will always have the most information available.” Monday’s comparison of provider health feeds shows how to route that feed into your ITSM tool, and our free cloud status heatmap gives a quick cross-provider view.

After the event, rerun the risk score on any change that was delayed or rushed through. The change risk score tool makes the “provider degraded” factor explicit, so the record shows why the team made the call it did.

What do UK resilience rules expect?

This section summarizes published regulator material and is not compliance advice.

Many of the firms named in coverage are regulated by the Financial Conduct Authority. The FCA’s operational resilience page says its rules came into force on March 31, 2022, and that in-scope firms “had until 31 March 2025 to ensure they could operate their important business services within their impact tolerances.” Firms are expected to have identified important business services, set “impact tolerances for the maximum tolerable disruption,” tested against severe but plausible scenarios, and run lessons-learned exercises.

A single-zone power loss at a hyperscaler is about as plausible as severe scenarios get. Firms with UK obligations should be able to show whether their important business services stayed within tolerance on October 20, and if not, which zonal dependency broke. EU firms face similar questions under DORA, which we covered in our DORA checklist for change managers.

What to do about it

  1. Find your zonal workloads. List every standalone Cloud SQL instance, zonal GKE cluster, zonal persistent disk and single-zone VM in production. Google’s reliability guide is a good checklist of what counts as zonal.
  2. Check failover capacity, not just failover design. For regional MIGs and GKE node pools, confirm the surviving zones can carry peak load without creating new instances. If they can’t, decide whether to overprovision or accept the risk in writing.
  3. Turn the failover into a standard change. Write the zone-evacuation and region-failover steps as pre-approved standard changes with named approvers and a tested runbook.
  4. Add an automatic freeze trigger. Block non-urgent deploys to any region with an active, relevant provider incident, and log overrides. Route Personalized Service Health events into your ITSM tool so the trigger fires early.
  5. Map dependencies one level down. If a SaaS vendor you rely on runs in europe-west2, you inherited this outage. Our guide to provider-of-provider risk covers how to find those dependencies.
  6. Hold a review when Google publishes its analysis. Compare Google’s root cause with your own impact timeline and record any changes to architecture or runbooks. Use the cloud and SaaS hub for our other provider incident timelines.

FAQ

When did the Google Cloud europe-west2 outage happen?

Google’s incident page gives the start as 23:08 US/Pacific on October 19, 2026, which is 06:08 UTC on October 20, and the end as 07:00 US/Pacific (14:00 UTC). Google lists the duration as 7 hours 52 minutes.

What caused the outage?

Google said “a power event caused an outage within europe-west2-b zone.” It hasn’t published more detail. Google said it will publish an analysis once its internal investigation is complete. Until then, treat any more specific cause as unconfirmed.

How many Google Cloud products were affected?

Google’s incident page lists 38 products, including Compute Engine, Persistent Disk, Google Kubernetes Engine, Cloud SQL, Spanner, BigQuery, Cloud Storage, Pub/Sub, Cloud Run, Cloud Load Balancing and VPC. Google noted that Looker Studio was not affected.

Why were services outside europe-west2-b affected?

Google’s symptoms said some services elsewhere in the region saw elevated errors and intermittent network issues. Google hasn’t explained why. Regional services rely on surviving zones having enough capacity and on regional control and network services, so a zone loss can still degrade them.

Would a multi-zone design have prevented impact?

It would have reduced it. Google documents regional resources as resilient to a single-zone incident, and Cloud SQL HA fails over to a standby in another zone. But regional MIGs don’t add instances without autoscaling, and Google warned customers might not be able to create new workloads, so spare capacity matters.

Should we freeze changes during a cloud provider incident?

For non-urgent changes in the affected region, yes. Deploying into a degraded region makes diagnosis harder and adds risk. Keep emergency fixes and the pre-approved failover change outside the freeze, and log every override with a reason.

Sources

#google cloud #europe-west2 #outage #zonal failure #resilience #change freeze #operational resilience

Published October 21, 2026.