Google Cloud outage in London: what one zone's power event broke

On Tuesday morning a Google Cloud outage hit London. A power event took out one zone of the europe-west2 region, europe-west2-b, and for a few hours UK banking apps, a delivery firm and the courts' remote-hearing video links reported problems. If you run anything on a public cloud, this one is worth ten minutes: zones exist precisely so that one building's bad morning stays one building's problem, and on Tuesday that only partly worked.

TL;DR

• Google's status page puts the start at 23:08 PDT on October 19, which is 07:08 in London. For hours the only description was "elevated errors and intermittent network failures", and the workaround field said "None for now".
• At 12:12 London time Google named the cause: "Due to a power event we had suffered an outage within europe-west2-b zone." Services in that zone were unavailable, and "some services in europe-west2 region may experience elevated errors". Thirty-eight products are listed on the incident.
• By 13:10 London time Google said most workloads were recovering, and at 15:03 it called the issue mitigated for most customers and promised a full analysis. It recovered existing workloads first and warned that customers might not yet be able to create new ones.
• Revolut told the BBC its disruption came from a third-party issue. HSBC apologised and said the situation was "also affecting other organisations". The BBC notes most firms had not officially tied their problems to Google.
• The same region failed in July 2022 after a cooling failure, and Google's own incident report admitted that regional services, which are designed to survive the loss of one zone, were hit anyway.

What happened in the Google Cloud outage, hour by hour

Google writes its incident updates in Pacific time, which is a slightly cruel choice for a London outage, so here is the log converted. All quotes are from incident Xs2XTHzAVC9YnafnPyzj.

Two details stand out. The first public post went up almost two and a half hours after the start time Google gave. And the best advice on offer was to move your workload somewhere else, which only works if you built for it before the morning started.

At 15:03 London time Google called it mitigated for most customers, closed the public update stream, and promised an analysis once its internal investigation is complete. There is still no root cause beyond "power event". I am not going to guess what failed in the building; when the analysis lands, that is the document to read.

How availability zones are supposed to contain a power event

A Google Cloud region is a geographic area, here London, split into zones. Google's regions and zones documentation puts the idea plainly: "Putting resources in different zones in a region reduces the risk of an infrastructure outage affecting all resources simultaneously. Putting resources in different regions provides an even higher degree of failure independence." europe-west2 has three zones, a, b and c.

Some resources are zonal. A Compute Engine VM lives in exactly one zone, and so does a zonal persistent disk. If your VM and its disk sit in europe-west2-b, Tuesday's power event was your outage, and no amount of Google's regional engineering changes that. Other services are regional: Google runs them across zones so that the loss of one zone costs capacity, and customers do not see an outage.

That gives you three layers to think about:

The middle row is the one most teams can afford, and it still costs money: you have to pay for spare capacity in the surviving zones, or accept a slower service while they absorb the load. That cost is the usual reason teams skip it.

A rough way to audit your own Google Cloud project is to list where your instances actually live:

gcloud compute instances list --format="table(name,zone,status)"

If one zone dominates that list for a production service, the next zone outage has your name on it. Google's docs also describe regional managed instance groups, which can spread instances across a region's zones; check that before the next incident rather than during it.

Why did one zone hit the whole region?

This is the part Tuesday's incident has not answered yet. Google's wording is that services in europe-west2-b were unavailable and "some services in europe-west2 region may experience elevated errors and intermittent network issues". So the other two zones did not fail, and yet some regional services degraded with the dark zone.

London has been here before. On July 19, 2022, in a heatwave, "a simultaneous failure of multiple, redundant cooling systems in one of the data centers that hosts the zone europe-west2-a impacted multiple Google Cloud services", according to Google's incident report. The report's "Regional Impact" section is unusually honest. It says regional services were affected "despite regional services being designed to survive the failure of a single zone", and it names two reasons:

1. "We inadvertently modified traffic routing for internal services to avoid all three zones in the europe-west2 region, rather than just the impacted europe-west2-a zone."
2. Regional storage, including Cloud Storage and BigQuery, replicates across zones, but because of that routing change those services "were unable to access any replica for a number of storage objects."

In other words, in 2022 the zone failed the way zones are allowed to fail, and a response step turned it into a regional problem. Google promised then to take "immediate steps … to improve the region's resilience." I can't tell you whether anything similar happened on Tuesday; Google's analysis is not out yet. What I can say is that the symptom pattern, one dark zone plus regional errors, is the same shape, which is why the report is worth waiting for.

Who was hit: Revolut, HSBC, Lloyds and the courts

Here is what the companies actually said, mostly to the BBC, which ran both an explainer article and a live page:

• Revolut: "We are currently experiencing a service disruption affecting multiple services," and its problems came from a third-party issue. It added that "all our customers' money and data are safe." Downdetector logged more than 1,500 user reports for Revolut shortly after 08:00 London time; those are user reports, which only tell you that people noticed.
• HSBC: "We are aware that some customers are experiencing difficulties accessing our services," and the situation "is also affecting other organisations."
• Lloyds: its app was functioning normally, but "we understand some are having issues with certain online services this morning." Halifax and Bank of Scotland, both in Lloyds Banking Group, also had problems.
• HM Courts and Tribunals Service said the video platform for remote hearings was affected, and the Criminal Bar Association said barristers could not proceed with some trials and hearings.
• DPD reported connection issues and later said they were resolved. The budgeting app Emma said it was back up after the Google Cloud outage, and the e-bike service Forest said part of its service had been affected.

The careful version: the BBC says most of these firms had not officially tied their problems to Google. Revolut said "third party" without naming it. I'm repeating what each company said, and I'm not claiming any specific bank runs on Google Cloud.

On Hacker News one commenter suggested that UK data-residency requirements push companies into a single in-country region. That's a guess from a commenter, and I have seen nothing that confirms it for any of the firms above, but it is the right question to ask your own compliance team: does "data stays in the UK" really require "everything in one region"?

What does a real backup look like?

Monzo has written up the far end of the table. Its main platform runs on AWS, and "Monzo Stand-in is an independent set of systems that run on Google Cloud Platform (GCP) and is able to take over from our Primary Platform … in the event of a major incident." Stand-in supports the essentials: card spending, cash withdrawals, bank transfers, balances and freezing cards. It's a smaller system on a different provider, and it exists for exactly the morning a provider has a bad day. That's an editorial pick of a good pattern; I'm making no claim about Monzo's status on Tuesday.

Most teams don't need a second cloud. The useful checklist after Tuesday is shorter:

• Know which of your production resources are zonal, and in which zone.
• Run stateless services across at least two zones, behind a regional load balancer.
• Use regional or replicated storage for anything the service needs to start.
• Practise losing a zone. A failover plan you have never run is a hope.

Also today: DHS orders DeepSeek out of federal agencies, and DeepInfer goes open source

The US Department of Homeland Security ordered DeepSeek products out of federal civilian agencies, under the Federal Acquisition Supply Chain Security Act of 2018, with publication in the Federal Register scheduled for October 20. The order excludes DeepSeek's products and services from civilian agency procurements and removes "all DeepSeek and DeepSeek-affiliate products, and third-party products and services developed using DeepSeek implementations, from civilian agency information technology." If you sell software to US agencies, that third-party clause is the line to read; I'm not interpreting its scope.

The same day, DeepSeek's newly open-sourced inference engine, DeepInfer, reached the top of Hacker News. DeepSeek describes it as "the high-performance inference framework that powers DeepSeek's large-scale production services", released under Apache 2.0. This release supports one model, DeepSeek-V4.1-Flash, on NVIDIA SM100 GPUs or Huawei Ascend 950 NPUs, for offline inference. The README lists what's missing for a complete service: a KV cache system, prefill and decode disaggregation, and load balancing across replicas. The feature I'd look at first is batch-invariant inference, which keeps results identical across different batch compositions when enabled (NVIDIA only).

Verdict: NEEDS REVIEW

I stamped it NEEDS REVIEW. A zone losing power is the failure zones exist for, and Google's zone design did keep the other two zones running. The open questions are why some regional services wobbled with one dark zone, in the same region where a 2022 report already explained how that can happen, and why so many UK services had one zone's worth of resilience on a Tuesday morning. I want the first answer from Google's incident report and the second from the companies themselves.

FAQ

What caused the Google Cloud outage in London on October 20, 2026?
Google says a power event caused an outage in the europe-west2-b zone. It called the issue mitigated for most customers at 15:03 London time and promised an analysis; no detailed root cause had been published when this was written.

Was all of europe-west2 down?
Google said services were unavailable in europe-west2-b, while some services elsewhere in the region saw elevated errors and intermittent network issues.

Was Revolut down because of Google Cloud?
Revolut said its disruption came from a third-party issue and that customers' money and data were safe. The BBC reported that most affected firms had not officially confirmed a link to Google.

What are availability zones?
Zones are separate parts of a cloud region designed to fail independently. Spreading resources across zones reduces the chance that one infrastructure failure takes them all down.

Sources

• Google Cloud Service Health: incident Xs2XTHzAVC9YnafnPyzj, europe-west2
• BBC News: Google Cloud says 'power event' behind outage hitting UK banks and websites
• BBC News live page on the outage
• Google Cloud incident report, europe-west2, July 2022
• Google Cloud documentation: regions and zones
• Monzo: Tolerating full cloud outages with Monzo Stand-in
• Hacker News discussion
• DHS notice of order, Federal Register 2026-21447
• DeepInfer on GitHub

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources