On October 22, Google Cloud posted a preliminary incident report on its status page for the europe-west2 (London) region: the disruption ran from 23:00 US/Pacific on October 19 (07:00 BST on October 20) to 05:10 US/Pacific on October 20 (13:10 BST), 6 hours 10 minutes in total. Our nodes aren't in Europe, but the report spells out something that is often overlooked: what "multiple availability zones" within one region can and cannot protect you from.
What Happened: From a Grid Disruption to a Whole Zone Losing Power
- At 22:53 US/Pacific (06:53 BST), the facility hosting availability zone europe-west2-b was hit by a power grid disruption. As designed, the load moved to UPS batteries while the on-site diesel generators started up.
- Both the primary and the backup PLC (programmable logic controller) automation systems that control the generators failed to initiate the automatic start and transfer, so the generators never took the load. From 23:00 the UPS batteries were depleted, and the zone's physical servers, network switching fabric and local storage lost power.
- Once grid supply was back, on-site engineers restored a stable utility feed within 1 hour, then reset and tested the generator automation controllers; Google restarted infrastructure step by step and gradually re-admitted traffic to zone b.
- Most services recovered within the first 5 hours 29 minutes (by 12:29 BST). Compute Engine took longer: new VM creation resumed at 12:46, and by 13:10 more than 99% of VMs were healthy.
Why Zones a and c Suffered Without Losing Power
The report names two causes. First, workloads from zone b surged onto zones a and c and exhausted the remaining capacity, causing queues, slower database failovers and intermittent 500 / 503 errors. Second, some services' control planes performed synchronous validation across zones, and the components that validation depended on were in zone b, which had lost power, so API calls timed out. Products the report names as unexpectedly affected include BigQuery, Looker, Compute Engine, GKE, Regional Persistent Disk and Cloud SQL. Resources hosted entirely in zone b were simply unreachable. The final report with preventive actions has not been published yet.
One more detail: the earliest status update that night gave the start time as 23:08 US/Pacific, which was actually when Google's monitoring raised the alert; the preliminary report uses 23:00. When you read a cloud provider's status page, expect the first few updates to be corrected by later reports.
Lessons for One VPS or a Few
- Keep backups in another region. A backup in the same facility or region becomes unreachable together with the original data when the whole site loses power. See VPS backup strategies.
- For important services, keep a machine in a second region — it can be a small cold standby — and keep DNS records on a short TTL so you can switch over when something goes wrong; see the DNS primer and picking a low-latency data center node.
- Map your dependencies. Zones a and c ran into trouble because what they depended on was in zone b. For mapping what your own services depend on, see dependency risk as H1 2026's defining outage pattern, and for the two Azure incidents at the end of September, see our summary of those reviews.
Update, November 7, 2026: Google Cloud posted its final incident report on November 4. It puts the main impact at 6 hours 8 minutes and explains why the generators never started: the facility was on a single utility feed during maintenance, and the controller's undervoltage sensing sat upstream of the open breaker on the other feed, so it saw a healthy source. See our follow-up.