GCP europe-west2 Outage: How One Zone's Power Failure Spread
The GCP europe-west2 outage on October 20, 2026 began when a grid disruption hit the facility hosting zone europe-west2-b and the controllers meant to start backup generators failed. The zone lost power for hours. Google's preliminary report says failover demand surges and cross-zone control-plane dependencies then degraded services in the other London zones.
The failure chain, from Google's preliminary report
Google posted a preliminary incident report for the europe-west2 event on October 22, 2026. The sequence it describes is short. A power grid disruption hit the facility hosting europe-west2-b. The facility's load moved to UPS batteries while the diesel generators were supposed to start. The Programmable Logic Controller automation that runs the automatic transfer to generator power failed, on both the primary and the backup controller. Generator power never took over. When the batteries were exhausted, hosts, network switching and local storage in the zone went offline.
Google's incident window runs from 23:00 Pacific on October 19 to 05:10 Pacific on October 20, 6 hours and 10 minutes, which is 07:00 to 13:10 in London. The incident was closed at 07:03 Pacific with a note that a very small number of customers were still affected. Accounts quoting about eight hours are measuring to that closure, not to the end of the main impact.
The detail worth dwelling on is the controllers. Redundant controllers that fail together are a common-mode failure: two copies of the same logic, the same configuration, or the same input will make the same wrong decision. Google has said a final report with preventive actions will follow, and that is where the specific cause of the controller failure should appear. Until then, any explanation of why both failed is speculation.
Why one zone's outage reached the other two
The physical outage was confined to europe-west2-b. Google's report still lists impact in europe-west2-a, europe-west2-c and regional services, and it gives two reasons: "instantaneous demand surges on unimpacted compute capacity" and "synchronous control-plane validation dependencies across zonal boundaries".
Demand surge on surviving zones
When one of three zones disappears, everything that fails over lands on the remaining two at once. Managed services with failover, which the report names as Cloud SQL, AlloyDB, Memorystore for Redis and Cloud Bigtable, did fail over. Customer autoscalers and instance groups also tried to replace lost capacity. The report describes elevated latency, HTTP 500 and 503 errors and admission queuing as that traffic concentrated on unaffected resources. The arithmetic is simple: two zones absorbing the work of three need roughly half again as much headroom, and they need it in the same minute that everyone else in the region asks for it.
Control-plane calls that cross zones
The second reason is subtler. If a request served from zone a must synchronously validate something against a component that lived in zone b, then zone a's data plane is healthy and its requests still fail, because the cross-zone call times out. The report says cross-zone calls to offline components timed out. This is the failure that zonal redundancy is supposed to prevent, and it usually lives in control paths that nobody draws on the architecture diagram.
Creating new capacity was the slowest part
At 04:58 Pacific Google warned that customers "may not be able to yet create new workloads" even as existing ones recovered. The report says new VM creation resumed by 04:46 Pacific and over 99 percent of VMs were healthy by 05:10. Google prioritised restoring what was already running, reprioritised scheduler allocations and capacity limits on unaffected infrastructure, and readmitted traffic to europe-west2-b gradually.
That ordering is sensible for the provider and awkward for anyone whose recovery plan is "spin up replacements in another zone". The plan works in a game day, when the region has spare capacity and the control plane is calm. It is least reliable during a real zone loss, when every tenant runs the same plan. Reserved capacity in the other zones, warm standbys that already exist, and failover that redirects traffic rather than creates instances are more dependable, and they cost money every day they are not used. That is the trade-off to make explicitly.
Seeing the incident: dashboard versus console
Readers reported that the public Google Cloud status page looked green while the Service Health section of the Cloud Console showed the incident, and that the first public update came late. Google's own timeline supports the lag: the power event began at 22:53 Pacific and the first incident update posted at 01:35. Those are user reports, not Google statements. The earliest update shown on Google's incident page is timestamped 01:35 Pacific, about two and a half hours after the stated start.
The practical lesson is to stop treating a provider's public dashboard as your detection mechanism. Your own synthetic checks and error-rate alerts will fire first. For confirmation, subscribe to the project-scoped Service Health feeds your provider offers rather than polling a global page, and route those notifications into the same incident channel as your own alerts so the timeline is in one place.
Questions to answer before the next zone fails
Which of your workloads are zonal by construction: single-zone instances, zonal persistent disks, single-zone node pools? Readers described a database that failed to start after failover, which is the kind of gap only a real failover exercise exposes. When did you last fail over each stateful component and bring it back? Do your surviving zones have the headroom to carry the load without creating new instances? Which of your internal services make synchronous calls that would cross into a dead zone, and do they have timeouts shorter than your user-facing deadline? None of these require knowing what failed in Google's generator controls. They only require assuming that, one day, a zone will be gone for six hours.
Frequently asked questions
- What caused the GCP europe-west2 outage?
- Google's preliminary incident report says a grid disruption put the europe-west2-b facility on UPS batteries, and the controllers that should have switched it to generator power failed on both primary and backup units. When the batteries ran out, hosts, networking and storage in that zone went offline. A final report with preventive actions is still to come.
- Why were europe-west2-a and europe-west2-c affected if only zone b lost power?
- Google's report names two reasons. Failover traffic created sudden demand surges on the surviving zones, causing latency, 500 and 503 errors and admission queuing. Some services also had synchronous control-plane validation that crossed zone boundaries, so calls into the dead zone timed out even from healthy zones.
- How long did the europe-west2 outage last?
- Google's incident window is 6 hours and 10 minutes, from 23:00 Pacific on October 19 to 05:10 Pacific on October 20, 2026, or 07:00 to 13:10 in London. Google closed the incident at 07:03 Pacific, which is why some accounts describe about eight hours. A small number of customers were still affected at closure.
- Is a multi-zone deployment enough to survive a zone loss?
- Only if the surviving zones have capacity ready and your services avoid synchronous dependencies on the lost zone. During this incident Google warned that new workloads might not be creatable while recovery ran. Designs that rely on launching replacement instances during a zone loss are weaker than warm standbys or reserved capacity.