Google Cloud's europe-west2 Outage: One Zone Lost Power and the Region Stalled for 6 Hours

On October 20, 2026, Google Cloud zone europe-west2-b in London went dark at 06:00 UTC because its backup generators never got a start command. The zone was down, but the region hurt too: cross-zone control-plane timeouts produced 500s, 503s and stalled jobs across europe-west2 for 6 hours 8 minutes. One zone failed, and the region went with it.

What happened, in UTC

Google's final report, published October 27, is unusually specific. The short version:

• 05:53 An underground cable fault cuts utility feed A. Feed B was already locked out for repairs after problems found in an October 14 generator load test, so the site was running on one feed.
• 05:53 to 06:00 The generator controllers (PLCs) check for voltage before starting the generators, but their undervoltage sensing inputs were wired upstream of the isolated feed B breaker. The PLC logic "indicated that a healthy utility source was available", so the generators never got a start signal. The static UPS, about five minutes of battery, carries the load.
• 06:00 The UPS runs out. Servers, local storage and network aggregation in europe-west2-b lose power.
• 06:09 Traffic fails over to the other zones, which brings cross-zone timeouts and capacity pressure.
• 08:35 First public status update, 2 hours 35 minutes after impact began.
• 11:12 First status update naming a power event.
• 11:46 New Compute Engine VM creation resumes.
• 12:08 Over 99% of Compute Engine VMs healthy. Closure notice followed at 14:03.

The status header lists 38 affected products and the final report 40, including Compute Engine, GKE, Cloud SQL, Spanner, Pub/Sub, BigQuery, Cloud Run, Cloud Storage and Persistent Disk. IncidentHub counted 12 downstream provider outages that cited this incident, including Stripe, Snowflake and MongoDB.

Why one zone took the region with it

Zones are designed so a power or cooling failure in one does not reach the others. The hardware isolation held: europe-west2-a and europe-west2-c stayed powered. What did not hold was the software layer above it. Google lists the symptoms in regional and multi-zone services as elevated latency, transient HTTP 500 and 503 errors and task admission queuing, because cross-zone remote procedure calls from regional service control planes timed out waiting on the offline zone. Some customers could not create, update or delete regional resources. Some failovers "were unsuccessful due to capacity constraints," and others hit storage replication difficulties.

That is the lesson worth sharing with your team. A three-zone deployment protects you from losing hardware in one zone. It does not protect you from the region's shared control plane slowing down while it waits on a dead zone, or from every other tenant in the region trying to claim the same spare capacity at 06:09. AWS customers learned the same lesson at a larger scale this year when AWS lost its Bahrain region and multi-AZ turned out not to be DR.

Am I affected? The audit to run now

If you run anything in europe-west2 (or any single region), these commands tell you which parts of your estate were one zone away from an outage:

# GKE: a LOCATION ending in -a/-b/-c is a zonal cluster with a single control plane
$ gcloud container clusters list --format="table(name,location,currentMasterVersion)"

# Cloud SQL: availabilityType should be REGIONAL; note primary and standby zones
$ gcloud sql instances list \
    --format="table(name,region,gceZone,secondaryGceZone,settings.availabilityType)"

# Compute Engine and zonal disks living in the zone that failed
$ gcloud compute instances list --filter="zone:europe-west2-b" --format="table(name,zone,status)"
$ gcloud compute disks list --filter="zone:europe-west2-b" --format="table(name,zone,sizeGb,type)"

Read the output this way:

• Zonal GKE clusters have one control plane. Google's docs say a regional cluster replicates it across zones, and "if a single zone becomes unavailable, your control plane is not impacted." You cannot convert a zonal cluster in place; plan a new regional cluster and migrate workloads.
• Cloud SQL with ZONAL is not recovered automatically from a zonal outage. You restore it by hand, through point-in-time recovery or by promoting a replica. With REGIONAL, failover starts after missed heartbeats, and the instance is unavailable for about 60 seconds. Test it before you need it with gcloud sql instances failover INSTANCE.
• Zonal disks without snapshots or regional replication in another zone are your data-loss surface.

What to change this quarter

1. Pre-reserve capacity in the surviving zones. VM creation in the region was not restored until 11:46 UTC, almost six hours in. Autoscaling that assumes it can create VMs during a zone failure is a plan that did not work on October 20. A zonal reservation holds capacity whether or not the region is under pressure:

$ gcloud compute reservations create web-failover-a \
    --source-instance-template=projects/PROJECT/global/instanceTemplates/web-n2 \
    --vm-count=6 --zone=europe-west2-a

Reservations cost money while idle. Size them for the critical path, not the whole fleet.

2. Alert on Personalized Service Health, not the public status page. The first public update came 2 hours 35 minutes after impact began. Personalized Service Health logs events relevant to your projects to Cloud Logging, so a log-based alert can page you directly. Google's example filter for new confirmed incidents, adapted to London:

$ gcloud services enable servicehealth.googleapis.com
# Log-based alert filter (Cloud Logging):
labels."servicehealth.googleapis.com/new_event"=true
AND jsonPayload.detailedCategory="CONFIRMED_INCIDENT"
AND jsonPayload.impactedLocations=~"europe-west2"

Your own synthetic checks will still fire first. Service Health's job is to tell you, early, that it is Google and not your deploy.

3. Write the multi-region runbook, then rehearse it. Google's own workaround text, first posted at 09:24 UTC, began "If feasible, the impacted customer may try to migrate their workload." For most teams it was not, because nobody had a second region ready. Pick the pattern from our comparison of active-active vs active-passive multi-region, decide which services need it, and keep data replicated there. Even a cold standby with tested restores beats a runbook that starts with "create the project."

Where this breaks

None of this makes a single region safe. A regional GKE control plane and REGIONAL Cloud SQL still sit on the same regional control plane that degraded on October 20; Google says some customers could not create, update or delete regional resources. Reservations guarantee capacity, not that the APIs to fail over onto it respond quickly. And multi-region costs real money in data transfer and duplicated stateful services, so most teams should apply it to a short list of revenue-critical paths rather than everything.

Questions people ask

What caused the Google Cloud europe-west2 outage on October 20, 2026?

A cable fault cut utility feed A to the facility hosting europe-west2-b while feed B was locked out for repairs. The generator controllers sensed voltage on the wrong side of the isolated breaker and never started the generators. The UPS ran out at 06:00 UTC, the zone lost power, and failover traffic plus cross-zone control-plane timeouts degraded the region for about six hours.

Does a regional GKE cluster survive a single zone outage?

Its control plane does. Google replicates a regional cluster's control plane across zones and says a single unavailable zone does not affect it. Nodes in the failed zone are still lost, so workloads need enough replicas and spare capacity in the remaining zones. During this incident, regional services also saw elevated errors from cross-zone timeouts, so expect degraded API responses even when the control plane stays up.

How do I get alerted about Google Cloud incidents faster than the status page?

Use Personalized Service Health. It writes service health events affecting your projects to Cloud Logging, and you can build a log-based alerting policy that filters on new confirmed incidents and impacted locations such as europe-west2. On October 20 the first public status update came 2 hours 35 minutes after impact, so your own synthetic monitoring should remain the first signal.

The call we'd make

Run the four audit commands today and fix the two cheapest findings first: zonal GKE clusters and ZONAL Cloud SQL instances on anything customer-facing. Add the Service Health alert this week, because it is one log-based alerting policy. Treat multi-region as a deliberate decision for your top revenue paths, written up the way we describe in post-mortems that drive change. The caveat: if your whole business runs in europe-west2 for data-residency reasons, check which locations your residency rules allow before you design a failover target around europe-west1.

Sources

• Google Cloud Service Health: europe-west2 incident and reports
• GKE regional clusters
• Cloud SQL: enable and test high availability
• Personalized Service Health example alerting policies