Update, 21 Oct 2026: Google has marked the incident resolved and says services have been restored. A Google spokesperson told the BBC the power event was at a third-party facility, and Reuters reports the UK financial regulator is speaking with Google and affected firms.
At 06:08 UTC on 20 October 2026, Google Cloud’s London region, europe-west2, started failing. According to Google’s incident page, a power event caused an outage in the europe-west2-b zone, and some services across the wider region saw elevated errors and intermittent network issues.
As of Google’s 11:12 UTC update, the power event was mitigated and partial recovery of infrastructure services was expected within 30 minutes, with the remaining services to follow. The incident was still open at the time of writing, with 38 services listed as affected. Google has not published a root cause beyond “a power event”.
What happened in europe-west2?
The Google Cloud London outage started in a single zone and spread into regional errors. The Register notes that europe-west2-b is one of three zones in the London region.
Google’s affected list reads like a full cloud stack: Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud SQL, Spanner, Bigtable, Pub/Sub, Cloud Storage and Persistent Disk. It also includes the shared plumbing: Cloud Load Balancing, Cloud NAT, Virtual Private Cloud, Private Service Connect and Network Connectivity Center.
In Google’s first update, at 08:35 UTC, the workaround field said “None for now”. From 09:24 UTC, Google advised customers to migrate affected workloads to another zone or region, if feasible.
Down Detector showed reported problems at Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Cloudflare, Screwfix and Revolut, according to The Register. Revolut said its customers’ money and data were safe. The Guardian carried the outage on its business live blog through the UK morning.
Why did one zone show up across the region?
Zones are meant to fail alone, and the shared services around them do not always let them. Spreading a workload across three zones assumes a building can lose power while the rest of the region carries on.
Google’s own symptoms went wider than the zone. The services that steer traffic away from a broken zone, such as load balancing, NAT and private networking, were on the affected list. When that layer wobbles, the failover path is under stress at the moment it is needed most. And “migrate if feasible” assumes you can still deploy, reach and move workloads in a degraded region.
None of this is a criticism of Google’s engineering. Every large cloud has shared regional services, and every one of them has bad mornings. The lesson is about what zone redundancy can promise.
A continuity plan is a decision, made in advance, about which work must keep running when infrastructure you do not control fails, where it runs, and how it behaves in degraded mode. Zone redundancy is a cloud design pattern. It protects the provider’s service. It does not decide anything about yours.
Why it matters as AI moves into the decision path
AI is moving from dashboards into decisions: approving payments, routing parcels, scheduling crews, adjusting plant. Each of those decisions inherits the availability of wherever the model runs and wherever its dependencies live, including identity, storage and the network in between.
When that is a region someone else operates, a power event in a building you have never seen becomes a pause in your operations. We set out the wider pattern of 2026 failures in The cloud has a blast radius. Today added one more data point, this time in London.
What it means for operators
The useful question is not “are we multi-zone?” It is these five:
- Which decisions must keep working if a region you do not control has a bad morning? Write the list.
- Where do those decisions run? If the answer is a region you cannot see into, that is a dependency, not a plan.
- What is the degraded mode? A last approved model, a smaller model, a rules-based fallback or a manual procedure, defined before the outage.
- Who holds the switch? The operator should be able to move into degraded mode at the site, without a console that lives in the affected region. We covered what that looks like in operator control for AI at remote sites.
- Have you cut it on purpose? Break the link on a schedule. The first real outage should not be the first test.
Where Sector88 fits
Sector88 is one system to deploy, run and govern AI at every site, connected or completely cut off. The decisions that cannot wait run where the work happens, under the operator’s command, with a defined fallback and a durable record of what ran. The cloud stays useful for everything that can wait.
Three zones is how a cloud stays up. It is not how your decisions stay up.