> ## Content Index
> Fetch the complete content index at: https://www.dailyferment.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# One cloud zone lost power. Why did banks go dark?
- URL: https://www.dailyferment.com/cloud-zone-outage-banks-restart-path/
- Published: 2026-10-21T06:29:33.000Z
- Updated: 2026-10-21T06:29:33.000Z
- Description: A power event in one of Google's three London zones disrupted bank apps for hours on 20 October. The 2019 Thameslink lock-out shows where outages are really lost: the restart.
- Author: Rana Bilal Zafar
- Tags: Fintech, Engineering, #reframe

Google's first public notice about Tuesday's London outage went up at 08:35 UTC, two hours and 27 minutes after the trouble started. Under "Workaround" it said: "None for now".

By then people in Britain had spent the morning unable to get into banking apps. Revolut said it was "experiencing a service disruption affecting multiple services" and that "all our customers' money and data are safe." Halifax said customers were "having issues with our app and online." Down Detector lit up for Lloyds, HSBC, Royal Mail, DPD and others. Even the courts' video platform for remote hearings had problems.

The cause, Google said at 11:12 UTC, was a power event in one zone, europe-west2-b. London has three zones. So the question I wanted to answer is simple: why does one building losing power take a bank's app down, when the whole point of three zones is that one can fail?

## The short answer

**2 h 27 min**from the stated start (06:08 UTC) to Google's first public notice

**38**Google Cloud products listed on the incident

**2 h 48 min**from "power event is mitigated" to the incident's end

**3**zones in the London region; one lost power

Source: Google Cloud Service Health, incident Xs2XTHzAVC9YnafnPyzj, 20 Oct 2026\. Durations are my arithmetic from the posted times.

I don't think the power cut explains it on its own. Google posted that the power event was "mitigated" at 11:12 UTC. The incident ran until 14:00 UTC, almost three more hours, and in between Google said it was "prioritizing the recovery of existing workloads" and that "Customers may not be able to yet create new workloads." The failover advice, when it came, was for customers to "migrate their workload impacted to another available location (zone or region)", if feasible.

Moving to another zone is the backup plan. If you're being told to do it by hand, in the middle of the outage, the backup was only ever a plan.

1. **06:08 UTC** Stated start of the incident in europe-west2
2. **08:35 UTC** First public notice. Workaround: "None for now"
3. **11:12 UTC** Google names a power event in europe-west2-b and says it is mitigated
4. **11:58 UTC** Recovery of existing workloads first; new workloads may not be creatable yet
5. **12:10 UTC** Recovery for most workloads in the region
6. **14:00 UTC** Incident end; "a very small number of customers" still affected

Source: Google Cloud Service Health, incident Xs2XTHzAVC9YnafnPyzj, 20 Oct 2026.

## My first reaction, and why it was too easy

My first reaction was that this is the banks' fault. A bank that runs its app in one zone of one region has chosen a single point of failure, and the cloud vendors have said for years that you should spread across zones. The FCA says much the same: if a supplier fails and you go past your impact tolerance, "the failure to remain within impact tolerance is your responsibility."

Then I read Google's notices more carefully. The symptoms line didn't stop at the one zone. It said "some services in europe-west2 region may experience elevated errors and intermittent network issues." And creating new workloads, which is what moving to another zone means, wasn't reliably possible for a while. Google has been here before. In Frankfurt in October 2024, a power and cooling fault in one zone was, for a stretch, described on its own status page as affecting the europe-west3 region before it was "back at zonal level."

So the honest version is less tidy. I don't know which banks ran in one zone and which ran in three and still struggled, because none of them has said. What I can see is that the escape route ran through the same region that was having a bad day.

## The cross: a train that wouldn't restart

Guess first: in the 2019 British power cut, how long did the grid frequency take to get back to normal, and how long did the stranded trains take?

The frequency was back at 50 Hz about **3 minutes 36 seconds** after the event began. **22 of 29** locked-out trains needed a technician on site, and full service took up to **a day** to return. Source: ORR, Railway power disruption report, 3 Jan 2020.

On 9 August 2019, at about 16:52, what the regulator thinks was a lightning strike on a transmission line knocked generators off the grid. The Office of Rail and Road's report on what happened to the railway is one of the clearest documents I know about where outages really come from.

The grid frequency dropped below 49.0 Hz for about 33 seconds and was back at 50 Hz roughly three and a half minutes after it started. That was the power problem. It was over almost at once.

![A white Thameslink Class 700 train arriving at a London platform](https://storage.ghost.io/c/d7/b7/d7b77195-48c5-45ab-8688-51750879d1d6/content/images/2026/10/df63-thameslink.jpg)

A Thameslink Class 700 at London Blackfriars, 29 September 2019\. Photo by [Sam](https://unsplash.com/@omegamezle?ref=dailyferment.com) on [Unsplash](https://unsplash.com/photos/white-train-on-train-track-J-UAcrdW33w?ref=dailyferment.com)

Twenty-nine Thameslink trains locked themselves out within 200 milliseconds of the dip. Seven drivers cleared the fault with a reset. The other 22 trains needed a technician on site, because a newer software version treated low frequency as a reason for a permanent lock-out instead of a temporary one. The ORR's verdict: "the temporary reduction in frequency should not have been considered a situation that requires a permanent lock-out." There were 371 cancellations and 220 part-cancellations, and full service took up to a day to come back.

A three and a half minute power dip cost a day because the restart path had never been run under real conditions. The trains were safe. They just couldn't come back without someone walking to them with a laptop.

Same shape, seven years apart

#### Thameslink trains, 9 Aug 2019

- *Fault* Grid frequency under 49.0 Hz for about 33 seconds
- *Fault over* About 3 min 36 s
- *Restart* 7 trains reset by drivers; 22 needed a technician with a laptop
- *Why* New software made a brief dip a permanent lock-out
- *Cost* 371 cancellations, 220 part-cancellations

#### Google Cloud London, 20 Oct 2026

- *Fault* Power event in one of three zones
- *Fault over* "Mitigated" posted at 11:12 UTC
- *Restart* Existing workloads first; new ones not reliably creatable
- *Why* Not published yet; analysis promised
- *Cost* Bank apps, parcels and court video links disrupted for hours

Sources: ORR report (3 Jan 2020); Google Cloud Service Health (20 Oct 2026); ABC News and The Register (20 Oct 2026).

Put the two next to each other. The fault was short or contained both times. The hours went into getting things running again: a reset that needed a person, a migration that needed spare capacity in a region that was itself wobbling. Somebody had designed each restart. Nobody had run it against the failure that actually came.

![Diagram: the Google Cloud London incident on 20 October 2026 from 06:08 to 14:00 UTC, split into no public notice until 08:35, the power event until 11:12, and the restart until 14:00; below, the 2019 Thameslink case where a power dip of about 3 minutes 36 seconds was followed by up to a day of restart, with 22 of 29 trains waiting for a technician](https://storage.ghost.io/c/d7/b7/d7b77195-48c5-45ab-8688-51750879d1d6/content/images/2026/10/df63-restart.png)

Where the hours went. Sources: Google Cloud Service Health; ORR (2020).

## What the rules already say

Britain changed the rules for exactly this kind of morning. In July 2026 HM Treasury designated four cloud providers, Google Cloud EMEA among them, as critical third parties to the financial system, effective 13 July, according to Herbert Smith Freehills Kramer's summary of the designations. The Bank of England, the PRA and the FCA now oversee the services they give to banks, including how they communicate with regulators and with the firms that rely on them during a major incident. Tuesday looks like the first big test of that since designation. A first notice two and a half hours in will be one of the things they look at.

The designation doesn't let banks off. The Treasury said designation "does not imply any judgement on the quality, security or reliability of the services", and banks remain responsible for their own contingency plans. That's the same point I made about a bank breached through a contractor's gateway: [the duty doesn't move when the work does](https://www.dailyferment.com/bank-breach-third-party-gateway-non-delegable-duty/).

And the FCA has already told firms where the gap usually is. Its review found firms "primarily relied on recovery" to judge whether they'd stay within tolerance, with limited testing of their response plans, and it wants more empirical testing, failover tests among them. It's the Thameslink report again, written by a regulator.

## What I'd ask after Tuesday

If I ran technology at a bank, I wouldn't start with "were we multi-zone?" I'd start with: when did we last actually move a live service out of a zone, on a weekday, without warning anyone first? And did anything need a person with a laptop?

The claim, in one sentence

A backup you have never switched to is a plan, not a backup, because outages are lost in the restart, and the restart is the part nobody rehearses.

## How sure am I?

Established

The timings and wording of Google's notices, Revolut's and Halifax's statements, the 2019 train figures from the ORR report, the CTP designation and the FCA's guidance.

Inferred

That the restart path, not only the power cut, set how long the banks were down. Google hasn't published its analysis and no bank has said how its systems were laid out, so this could change.

Guess

That the CTP regime will push banks and cloud providers into joint restart drills, not just more paperwork.

I'll come back to this when Google publishes its incident report.

## Sources

- Google Cloud Service Health, incident Xs2XTHzAVC9YnafnPyzj, europe-west2, 20 Oct 2026 ([status.cloud.google.com](https://status.cloud.google.com/?ref=dailyferment.com))
- The Register, "Google Cloud's London zones takes a nap, multiple services disrupted", 20 Oct 2026 ([www.theregister.com](https://www.theregister.com/paas-and-iaas/2026/10/20/google-clouds-london-zones-takes-a-nap-multiple-services-disrupted/5304084?ref=dailyferment.com))
- The Register, "Google Cloud says a 'power event' caused today's outage", 20 Oct 2026 ([www.theregister.com](https://www.theregister.com/paas-and-iaas/2026/10/20/google-cloud-says-a-power-event-caused-todays-outage/5304160?ref=dailyferment.com))
- ABC News, "European banks, websites hit as Google Cloud data centre goes offline for hours", 20 Oct 2026 ([www.abc.net.au](https://www.abc.net.au/news/2026-10-20/google-cloud-failure-europe-banks/107290238?ref=dailyferment.com))
- Herbert Smith Freehills Kramer, "HM Treasury makes first designations under UK CTP regime" ([www.hsfkramer.com](https://www.hsfkramer.com/notes/fsrandcorpcrime/2026-posts/hm-treasury-makes-first-designations-under-uk-ctp-regime?ref=dailyferment.com))
- FCA, "Operational resilience: insights and observations for firms" ([www.fca.org.uk](https://www.fca.org.uk/firms/operational-resilience/insights-observations?ref=dailyferment.com))
- Office of Rail and Road, "Railway power disruption report", 3 Jan 2020 ([www.orr.gov.uk](https://www.orr.gov.uk/media/10752/download?ref=dailyferment.com))