TL;DR
- Google Cloud europe-west2 is the company's London region, and a region is a group of separate data centre sites called zones which Google designs to limit correlated failures from physical infrastructure outages.
- A power event in one of those sites, europe-west2-b, caused an outage on 20 October 2026, and Tech AI Wire counts 41 Google Cloud products as affected, with elevated errors and intermittent network issues also reported across the rest of the region.
- The recorded incident length is 7 hours 52 minutes, running from 07:08 to 15:00 London time, and the status page described the power event as mitigated by 04:12 Pacific time.
- Revolut's own status page listed card payments, transfers and sign-in as down, and users of Lloyds, HSBC and Bank of Scotland reported problems.
- Google told customers they could move workloads to another zone or region, and its final status update said that a very small number of customers were still affected.
- Zones exist so a single failure stays contained, and the errors reported across the rest of the region raise a question that only Google's promised analysis can settle: which shared services carried the effects of a single-zone power failure beyond europe-west2-b.
- An architecture review should map each dependency to a zone, document a path through a region-wide error and record the last failover drill.
Google Cloud's own Service health dashboard (status.cloud.google.com, captured 2026-10-20), showing the europe-west2 incident banner, the affected product list and the timestamps Google published during the day.
What the status page recorded on 20 October
Google's service health dashboard opened the incident at 23:08 Pacific time on 19 October, which is 07:08 in London, and closed the customer-facing part of it at 07:00 Pacific the next day, 15:00 in London. Tech AI Wire reports that the status page puts the duration at 7 hours 52 minutes.
The cause Google published is one sentence long. A power event caused an outage within europe-west2-b zone, the power event is mitigated, and services are recovering with existing workloads prioritised, and customers may not be able to create new workloads yet. Tech AI Wire reports 41 affected products on Google's status page. Reported among them are Compute Engine, Kubernetes Engine, Cloud SQL, Cloud Storage, BigQuery, Cloud Spanner, Pub/Sub, Cloud Run, Persistent Disk and Cloud Load Balancing.
The update sequence reads like a queue draining. According to Tech AI Wire's timeline, at 01:35 Pacific Google started investigating, at 04:00 it told customers to move workloads to another zone or region, at 04:12 it reported the power event mitigated, at 04:58 it reported services recovering and warned that new workloads may not start, and at 07:03 it reported the issue mitigated for most customers with a very small number still affected. The Register quotes Google's final status-page update as saying that the issue was mitigated for most customers, with a very small number still affected, and that no further updates would follow on the page.
Netics editorial diagram built from Google's status page as reported on 2026-10-20: one zone lost power, 41 products were listed as affected, and the recorded incident ran 7 hours 52 minutes.
How one zone reaches services in the other two
A zone is supposed to be the failure domain. Google's documentation says it designs zones to minimize the risk of correlated failures caused by physical infrastructure outages, and the reported errors across the wider region make this incident's reach worth examining.
The status page reported a full service outage in europe-west2-b. It also reported elevated errors and intermittent network issues across the wider region. Google has published no cause beyond the power event, so a shared regional dependency remains one possible explanation for the wider errors. That shared-dependency mechanism remains an unconfirmed hypothesis in the cited reporting. Google has promised an analysis once its internal investigation closes, and that document will show whether the hypothesis holds.
The services disrupted on Tuesday morning
Tech AI Wire reports that Revolut's status page listed ATM withdrawals, identity checks, card payments, transfers, sign-in, chat support and stock and crypto trading as down. Tech AI Wire reports Downdetector outage reports from customers of Lloyds, HSBC and Bank of Scotland; the Wandsworth Guardian reports that HM Courts & Tribunals Service experienced issues with its cloud video platform for secure video links to court hearings in England and Wales.
Google Cloud's official Regions and zones documentation (cloud.google.com/compute/docs/regions-zones, captured 2026-10-20), which defines regions as independent geographic areas that consist of zones.
Zones exist so a single failure stays contained
Every hyperscaler sells the same design: spread across zones, survive a zone. The design works when the application actually spreads. Here is an invented illustration that describes no real company and no part of this incident. A logistics operator runs its order database in one zone and its queue in another, keeps both behind a single regional load balancer, and calls a payment provider whose own endpoint sits in a zone nobody checked. The regional load balancer's configuration and the provider's capacity remain in the failure path, allowing a zone loss to stop the morning's operations.
The lesson from a day like this one travels across architectures: the failure domain that matters is the one your dependencies share. DevOps pipelines and managed monitoring is where that mapping gets written down for most teams.
Netics editorial checklist assembled from the europe-west2 incident of 2026-10-20: map the zone of every database and VM, keep a tested path to a second region, run a failover drill, and read Google's own analysis.
What an architecture review should change
Start with an inventory of where things run. Which zone holds each database, queue and VM, and which of those were placed there by a default that nobody revisited. Then check the shared paths: the load balancer configuration, the DNS records, the identity provider, the payment or messaging provider whose own resilience nobody asked about.
Failover deserves a drill with a dated report. Google's advice during the incident was to move workloads to another zone or region. Teams that have practised the move and can start new capacity while the control plane is degraded can act on that advice. The status page also warned that customers may not be able to create new workloads yet. In that state, a workable disaster recovery plan needs pre-provisioned capacity.
The last item costs nothing. Google will publish its analysis of the incident, and reading it before the next architecture review turns a vendor's postmortem into a specific question about your own dependency graph.
Originally published on the Netics blog.
Top comments (0)