A London Zone Went Dark. Here's the Operator's Checklist It Just Audited for You

A power event in europe-west2-b, one of three availability zones in Google Cloud's London region, began at 23:08 PDT on 2026-10-19 and took a long roster of services with it: AlloyDB for PostgreSQL, Cloud Load Balancing, Cloud SQL, Spanner, Firestore, GKE, Cloud Run, Persistent Disk, Private Service Connect, Cloud NAT and VPC (status page). The Register puts the start of downtime at 0608 UTC, the same moment (The Register). Google's 05:44 PDT update said it was seeing recovery for most workloads in europe-west2 as of 05:10 PDT on 2026-10-20 (status page). Google closed the incident at 07:00 PDT and says it will publish an analysis once its internal investigation is complete.

Revolut said the outage disrupted multiple services, with card payments and ATM withdrawals affected. Downdetector showed reports touching Lloyds, HSBC, Rightmove, DPD, NHS England and Royal Mail, and Lloyds and HSBC both acknowledged customer issues. ING Germany also flagged website and app problems but said there was no indication of any connection to third-party providers (Reuters). Those brands hadn't confirmed a cause, so read the list as an indication of blast radius. None of it is confirmed attribution.

Google has not yet published a root-cause analysis, though it has committed to one. The only official cause statement is "a power event," and Google told The Register the only information available is on the status page (The Register). So this piece won't guess at why. It will deal with the part you control.

What this incident actually tested

One detail changes the whole lesson: this was a zonal failure inside a region that largely stayed up. The only workaround Google offered was that, if feasible, impacted customers might migrate affected workloads to another available location, zone or region, and an earlier 01:35 PDT update said "None for now" (status page).

So the estates that broke were, in the main, the estates pinned to one zone. The failure mode under audit in the 2026-10-20 event is zone-pinning, not a regional problem. It isn't an argument that you need a second region, and we'd rather you didn't spend this week's unlocked budget as though it were.

The checklist a zone failure writes for you

When our managed operations team walks an estate after an event like this, the written recovery objective and the demonstrated one tend to come apart in the same four places. The first artifact worth pulling is a zone-pinned inventory by project: every instance, database and node pool whose location field names a single zone rather than a region. That list is usually longer than the recovery document assumes.

• Zonal compute. Google's Compute Engine SLA sets a Monthly Uptime Percentage of at least 99.99% for "Instances in Multiple Zones." A single instance of other families, on Premium Tier in Cloud Regions and excluding Stockholm, gets at least 99.9%; Load Balancing is at least 99.99% (Compute Engine SLA). The headline number most recovery documents assume is conditional on how you deployed. SLA pages change, so confirm the current figures before you quote them in a board pack.
• Non-HA Cloud SQL. An HA-configured instance is a regional instance with a primary and a standby in two zones in the same region. It replicates synchronously between them, and on instance or zone failure the standby becomes the new primary (Cloud SQL HA docs). That's exactly this failure. It costs twice a standalone instance, and that premium spans CPU, RAM and storage, pricing as documented at time of writing (Cloud SQL HA docs).
• Single-zone GKE node pools. The cluster is only as regional as the nodes under it. Read each cluster's node pool locations: a pool listing one zone disappears when that zone does, even if the control plane is regional. A regional control plane survives the loss of a zone, but it doesn't keep the nodes under it alive.
• Load balancer failover that was never drilled. A health check configuration is a hypothesis until something fails behind it. A real drill means removing a backend in one zone during business hours, timing how long traffic takes to settle, then comparing that number with the recovery objective you published.

Cross-region is a different purchase, with a different receipt

If you do decide a second region is warranted, buy it with eyes open. Cloud SQL is a regional service: if the region hosting the database becomes unavailable, so does the database, and the documented disaster recovery plan requires configuring a cross-region read replica. Because that replication is asynchronous, the RPO is likely non-zero (Cloud SQL DR docs). RPO is the amount of recent data you accept losing. Non-zero means the writes in flight when the region went dark are simply gone.

The failover itself is a manual sequence: promote the replica in the secondary region, avoid split-brain, establish an initial backup, and recreate a replica in a third region to restore your DR posture (Cloud SQL DR docs). "We failed over" can still mean "we lost writes," and your risk committee should hear that sentence in advance.

The skeptical case deserves airtime too. Practitioners argue openly that multi-region isn't worth it. One engineer running a single region across three zones put it plainly: "We could be multi-region but the added cost wasn't worth the benefit and complexity." Another noted the engineering cost of resilient multi-cloud "almost negates the point of having the cloud" (Hacker News). Multi-zone is the proportionate fix for most workloads hit here.

The academic read lands in a similar place. Dr Amro Al-Said Ahmad of Keele University told The Register the incident shows "the dependency effect of modern cloud ecosystems" and that "resilience is not achieved by simply moving to the cloud. True resilience requires designing for regional failures through multi-region deployments, workload portability, and tested disaster recovery procedures"; he estimated 38 services were down, which matches the 38 products listed on Google's incident page (The Register).

The comms gap nobody budgets for

The second thing that goes wrong in a zone event is internal: no one can say quickly which projects were actually hit. Google positions Personalized Service Health as "your primary channel for incident information and service health events relevant to your projects," delivered via a console dashboard, a Service Health API, Cloud Logging-based alerts and log exports, with per-product and per-location disruption status and recovery timestamps during multi-product incidents (Service Health overview). It classifies each incident's relevance as Impacted, Related, Partially Related, Not Impacted or Unknown, with verified "Impacted" status available only for some products (Service Health concepts).

Wire those signals into the monitoring channel your team already watches. If your first signal of zone loss is Downdetector, the gap is in your reporting path. A GCP zone failure should surface in that channel before it surfaces in a customer's outage report.

Regulators are now part of your audience

Reuters notes the UK designated four technology companies, including Google Cloud EMEA Limited, as critical third-party suppliers to its financial sector in July. That designation brings them under direct regulatory oversight. Reuters also reports that Google Cloud was among 19 companies designated by EU regulators last year as critical third-party computing providers for finance (Reuters). The ESAs published that first list of 19 Critical ICT Third-Party Providers on 18 November 2025. The list includes Google Cloud EMEA, AWS EMEA, Microsoft Ireland Operations, Oracle Nederland and IBM, and it's updated annually (SureCloud). DORA's pillars include digital operational resilience testing. The framework also establishes an EU-wide oversight regime aimed at systemic and concentration risk (EIOPA).

If you operate in UK or EU financial services, the 2026-10-20 event is evidence you'll be asked about. Start from the regulator's own framing; plenty of concentration-risk commentary is published by firms selling the alternative.

Spend the war-room budget on drills as well as architecture

The recurring critique in disaster recovery literature is untested plans rather than missing infrastructure: one practitioner guide states flatly that "If you never test your DR plan, that means your DR plan is not working at all" (LINBIT), and Eon's 2026 disaster recovery audit checklist recommends testing at least quarterly for Tier 1 workloads with realistic failure scenarios, and RTO/RPO targets set per tier (Eon).

So tier the estate. Decide which systems justify an HA database at double the cost, which get a cross-region replica and an accepted non-zero RPO, and which can honestly tolerate a rebuild, and price in the recovery traffic and re-provisioned capacity each tier would generate, because a slow-moving budget signal can surface that spike well after the fact. That's a FinOps exercise wearing a reliability hat, and it's the one most teams skip.

If you want a second pair of hands on the zone-failure audit (inventory of zone-pinned instances, non-HA Cloud SQL, single-zone node pools, undrilled load balancer failover) our managed operations team scopes it as a fixed engagement. Either way, run the drill this quarter, while the memory is still expensive.