A single London zone can still take down a cloud supply chain

A power event in one Google Cloud availability zone disrupted banking, delivery, court and consumer services connected to the company’s London region on October 20, 2026. Google said the event in europe-west2-b had been mitigated and that it was recovering existing workloads, but warned that customers might still be unable to create new ones.

This was not a generic internet failure or a confirmed breach of every affected company. It was a regional infrastructure incident in one of the three availability zones in Google Cloud’s europe-west2 region, yet failures propagated into services far removed from the underlying power problem. Placing an application in a cloud region is not the same as designing it to survive the loss of part of that region.

Google initially described elevated errors and intermittent network failures across multiple services. Its later incident update attributed the failure to power and said the provider was prioritizing existing workloads over new deployments. The company projected full recovery of existing workloads by 13:00 UTC, tentatively, after its 11:58 UTC update. The official status record is documented in Google Cloud’s incident notice.

Recommended reading

Britain’s AI buildout is running into a power deadline, not a chip shortage

Sergey Kuznetsov • Oct 19, 2026 • 7 min read

“A power event caused an outage within europe-west2-b zone. The power event is mitigated. We are seeing the recovery of services and are prioritizing the recovery of existing workloads. Customers may not be able to yet create new workloads.”

One zone, many failed dependencies

The directly affected product list is more informative than the broad phrase “cloud outage.” The incident touched compute, storage, orchestration, managed file storage, analytics transfer and managed streaming services. A customer relying on several of these products can fail in ways that are not obvious from the application’s front end: a working web tier may be unable to reach a file share; a Kubernetes control-plane dependency may block a replacement workload; a data-transfer job may stall even when the core database remains available.

The temporary inability to create new workloads could turn a localized failure into a longer outage for systems that depend on autoscaling, replacement pods, emergency deployments or disaster-recovery provisioning. Google said it was recovering existing workloads first; none of the supplied reporting establishes when new workload creation was fully restored.

Google did not publish a technical root-cause analysis beyond “power event.” It did not say whether the initiating fault involved facility power, a distribution component, protection equipment, or the chain of infrastructure services that translated the event into network failures. Nor did it provide a count of customer projects or workloads affected. A power event is a cause category, not the postmortem engineers would need to assess whether a similar failure mode can recur.

Customer failures were uneven and not all formally linked

Revolut confirmed a third-party service disruption after more than 1,500 user reports shortly after 08:00 BST, and said customer money and data were safe. Lloyds Banking Group said its app was operating normally while acknowledging that some users had problems with certain online services. Halifax, Lloyds and Bank of Scotland users also reported trouble.

“We are currently experiencing a service disruption affecting multiple services. We can confirm that all our customers' money and data are safe.”

A company acknowledging disruption is not the same as confirming a Google Cloud dependency. Revolut identified a third-party issue but the supplied statement did not name Google. Lloyds said it was aware of similar problems at other organizations, not that Google Cloud caused its own issue. The available reporting establishes contemporaneous impact, but not a public architectural dependency map for every affected organization.

The HM Courts and Tribunals Service said its Cloud Video Platform for some remote hearings was affected and advised participants to contact the relevant court or tribunal if they could not join. DPD acknowledged website connection issues. Reports also included Rightmove, BT, Royal Mail, Screwfix, HSBC, Emma, Spotify and the NHS, though the degree of confirmation varies substantially. For example, reports said Spotify service returned during recovery, but no supplied material includes a Spotify statement tying its outage to the London zone.

Outward-facing services frequently combine multiple providers, identity systems, payment paths, application platforms and third-party APIs. A customer sees a failed app, not the availability zone, managed service or integration that caused it. Public outage pages tend to surface the dependency chain only after an incident is well underway.

The timeline has a timezone problem

The reports agree on the core sequence—failure, mitigation, then restoration of existing workloads—but their clock descriptions are not cleanly aligned. The Register put the start of trouble in europe-west2-b at 06:08 UTC on October 20. Mashable quoted Google’s status language as 23:08 PDT on October 19, which represents the same moment. Tom’s Guide, however, described the outage as first noticed at 07:08 UK time, an hour later than the UTC account. BBC News also said Google’s dashboard first indicated the incident on Monday evening UK time.

The first two entries reconcile as timezone representations of the same timestamp. The BBC and Tom’s Guide timing descriptions do not match that pair, and the supplied reporting does not explain whether they refer to dashboard publication, customer-visible impact, or a later escalation. For incident response teams, an accurate sequence is necessary to distinguish the initiating fault from alerts, customer reports and recovery actions.

Resilience requires a failure domain outside the region

A lecturer in computer science at Keele University estimated that 38 services were unavailable and described the event as an example of dependency effects in cloud ecosystems. The estimate has not been confirmed by Google, but the named product set shows the mechanism. An application can be deployed redundantly while retaining a regional dependency on storage, a control plane, message streaming, file services, batch transfers or an external SaaS integration.

Multi-zone deployment helps only if the relevant components span zones and fail over correctly. It does not automatically protect a workload that uses a zonal storage dependency, relies on a regional managed service with impaired control operations, or needs to create capacity during the incident. Multi-region architecture can reduce that exposure, but only if it includes data replication, traffic steering, credential and identity behavior, tested recovery procedures, and a way to operate when the preferred region cannot accept new workloads.

That design has costs: duplicated infrastructure, replicated data, operational testing and more complex failure handling. The October 20 incident does not establish which affected companies had multi-region designs, which had single-zone components, or which deliberately accepted the regional risk. It shows why availability claims that stop at “hosted in the cloud” are nearly meaningless.

The outage was geographically concentrated in Google Cloud’s London region rather than a Europe-wide Google Cloud failure. It is not evidence that all Google Cloud customers were down, nor that every organization named in user reports depended on the provider in the same way. It is evidence that one availability zone in a regional cloud platform can interrupt services ranging from retail banking interfaces to remote judicial hearings when the surrounding application architecture has no effective alternative path.

For organizations that treat a London-region outage as an acceptable event, the recovery target is the key metric. For organizations that cannot, the test is whether they can continue operating while an entire regional dependency—and the ability to create replacement workloads inside it—is unavailable. Google’s recovery update addressed the immediate incident; it did not answer that design question.