Google Cloud London outage: what it means for your exit plan

On 20 October 2026, a power failure at the data centre facilities of zone europe-west2-b caused a Google Cloud outage in London (europe-west2) lasting 6 hours and 8 minutes, according to Google’s final incident report of 27 October, revised on 4 November. Some workloads in the other two London zones were affected too, because failover ran into capacity limits and control-plane dependencies across zones. For organisations under DORA or FINMA’s rules, the outage shows that redundancy inside one provider is not an exit plan. DORA asks for exit plans that name alternative solutions and are tested, and such a plan works only if the data is already where the fallback runs.

This post covers what failed, why failover fell short, what DORA and FINMA require, what to do by when, and why open source makes an exit plan something you can run.

What happened in the Google Cloud London (europe-west2) outage?

Google’s report describes a site built with two complete power paths and running on one: the breaker on utility feed B was open for repairs after issues found in a quarterly generator load test on 14 October 2026. At 06:53 BST on 20 October, an underground cable fault outside the site cut feed A. The generators did not start, because the controllers’ voltage sensing was “wired upstream (line side) of the isolated utility feed breakers” and read the disconnected feed B as healthy.

Time (BST, 20 October 2026)	What Google reports
06:53	Utility feed A lost; the generators do not start
07:00	Batteries exhausted; servers, storage and network in europe-west2-b lose power
07:09	Automated failover to zones a and c begins; cross-zone control-plane calls time out, capacity saturates
07:54	Standby utility supply restored; data halls re-energised by 08:20
08:50	Storage devices that shut down uncleanly begin a long recovery
11:45	Controlled return of traffic to europe-west2-b
13:08	“Majority Workload Recovery”; the closure notice follows at 15:03

The report lists 40 Google Cloud products with impact in europe-west2 and identified no impact outside the region. Since the 4 November revision, its open action items run to 18 December, the last a new item on PLC code reviews during facility commissioning.

Reuters reported on 21 October (copy on Yahoo Finance) that the European Banking Authority “has been in contact with Google Cloud”, that the UK Financial Conduct Authority said it was engaging with Google, and that Parliament’s Treasury Committee had written to the Bank of England and the FCA. In a joint reply of 4 November 2026, the Bank of England and the FCA said they learned of the disruption “through affected firms, not initially through a notification from Google itself”, and that firms without sufficient assurance from a material third party “should strengthen their own contingency arrangements and consider practicable alternative provision”. A fuller reply is due by 20 January 2027. Google Cloud EMEA Limited has been a designated critical third party in the UK since 13 July 2026 (SI 2026/777), and is on the list of 19 critical ICT third-party providers the European Supervisory Authorities published under DORA on 18 November 2025. Neither designation moves responsibility: under DORA Article 28(1)(a), financial entities “remain fully responsible”, and Reuters notes the same of banks under UK rules.

Why did failover inside the London region fall short?

A zone is a failure domain inside one provider’s region, not a separate provider. The report names two causes of impact outside zone b: “Instantaneous demand surges on neighboring zones (a and c)” and “Control-plane dependencies across zonal boundaries”. For Kubernetes Engine, regional API operations “suffered increased failure rates for cluster creation, deletion, updates and node pool operations”; for Compute Engine, “some of these failover attempts were unsuccessful due to capacity constraints and difficulty in replicating the underlying storage mechanism”. The report is also plain that zonal resources such as virtual machines “require customers to provision cross-zone failover and recovery mechanisms tailored to their needs”.

Three lessons hold for any architecture:

• Spare capacity is shared. When a zone fails, many customers fail over at the same moment into the same pool.
• The control plane is a dependency. A recovery that creates resources through the provider’s API during the incident depends on that API.
• Redundancy is not independence. Google designs zones to limit correlated failures from physical outages, not to cover the provider’s region, platform or contract becoming unavailable. That is what an exit plan is for.

What DORA requires: concentration risk, exit plans and the register

DORA, Regulation (EU) 2022/2554, has applied to EU financial entities since 17 January 2025. Its third-party rules read like a checklist for this outage.

What London showed	What DORA asks	Where
An outage in one provider’s zone disrupted services for hours	Exit strategies covering “a possible failure on their part”	Art. 28(8)
Failover stayed inside one provider’s capacity and control plane	Assess whether a provider is “not easily substitutable” and whether several arrangements sit with the same provider	Arts. 28(4)(c), 29(1)
Recovery waited for the provider	Alternative solutions and transition plans to move services and data “to alternative providers or reincorporate them in-house”	Art. 28(8)
For zonal resources such as VMs, failover was the customer’s to provision	Yearly tests of continuity and recovery plans, including “switchovers between the primary ICT infrastructure and the redundant capacity”	Art. 11(6)

DORA treats the two cases separately: Article 11 covers continuity and recovery when a service is disrupted, as in London, and Article 28(8) covers exit when a provider fails or has to be left. A fallback in a failure domain you choose serves both.

Exit plans “shall be comprehensive, documented and … sufficiently tested and reviewed periodically” (Article 28(8)). Delegated Regulation (EU) 2024/1773 adds in Article 10 that each plan must take into account “unforeseen and persistent service interruptions”.

The register of information makes the answers visible. Template B_07.01 of Implementing Regulation (EU) 2024/2956 asks, for each ICT service supporting a critical or important function, how substitutable the provider is, whether an exit plan exists, whether the service could be reintegrated and whether alternative providers have been identified. A “yes” in the exit-plan column should point to a plan that has run.

DORA does not require two providers: a multi-vendor strategy is something entities “may” define (Article 6(9)). It requires that losing or leaving a provider has been thought through and tested.

What FINMA expects from Swiss banks

FINMA’s Circular 2023/1 on operational risks and resilience applies to banks and securities firms. They identify critical functions and a tolerance for disruption for each (margin no. 101), keep an inventory of the dependencies behind them (no. 107), and test that critical functions stay within tolerance in “severe but plausible scenarios” (no. 110). Footnote 27 names “a power shortage” and “a prolonged downtime resulting from the insolvency of a key service provider” among the examples.

Since 1 January 2026, when the transition in margin no. 113 ended, every institution must take measures to ensure operational resilience (no. 102), regardless of its supervisory category, as FINMA’s Guidance 05/2025 of 10 November 2025 recalls. In its survey of 267 institutions, it found that 71% of the critical functions reported depend directly or indirectly on third parties.

Where critical processes are outsourced, the disaster recovery plan must take into account “external dependencies and contractual provisions as well as alternative solutions” (no. 88), and the most important measures are tested at least once a year (no. 92). Circular 2018/3 on outsourcing adds that where several functions go to one provider, “the concentration of risk must be taken into account” (no. 17), and that provision must be made for bringing a function back in house or transferring it “in an orderly manner” (no. 18.1).

What to do, and by when

Legal dates come from DORA, FINMA and the Data Act; the other dates are our suggestion.

1. Now, for Swiss banks and securities firms: add a provider outage and a stressed exit to your scenarios. Measures for severe but plausible scenarios have been required since 1 January 2026 (margin nos. 102 and 113).
2. By 30 November 2026: record what this outage would have done to you. Whether or not you use Google Cloud, list the critical functions that run in a single region or on one provider’s managed services, and how long each could stop against its tolerance or recovery time objective. The date is ours.
3. By 31 December 2026: map failure domains, not only providers. For each critical function, note the zone, region, provider, managed control plane (database, Kubernetes, identity, DNS) and backup location it depends on, and which it shares with other functions. That feeds the inventory of FINMA margin no. 107 and the concentration assessment of DORA Article 29. The date is ours.
4. Before your next register submission: answer B_07.01 honestly. DORA requires a yearly report on new ICT arrangements and the full register on request (Article 28(3)), and national authorities set the dates (in 2026 the CSSF collected registers from 11 February to 31 March). Check your authority’s dates for 2027.
5. By 31 March 2027: run one exit test, not only a failover test. Restore a critical service from backups held outside its provider onto infrastructure you choose, and time it against your tolerance. DORA Articles 11(6) and 28(8) and FINMA no. 92 ask for the tests; the date is ours; see what a restore test proves.
6. At each renewal: write the way out into the contract. A transition period (DORA Article 30(3)(f)), data returned in an easily accessible format (Article 30(2)(d)), named locations (Article 30(2)(b)) and an orderly transfer (FINMA no. 18.1). From 12 January 2027, the Data Act also ends switching charges, egress included.

An exit plan runs only if the software can run elsewhere

The register’s questions on substitutability and reintegration come down to one: could the service run somewhere else within its tolerance, with your data? For a proprietary managed service, the alternative is often a different product, so the exit is a migration project, written in a plan that is hard to test. For open-source software, the alternative can be the same software on other machines, such as PostgreSQL on your own servers instead of a managed PostgreSQL service, or the same interface, such as an S3-compatible store like Garage instead of a provider’s object storage. The core of the exit test becomes a restore, which can run every month.

Three things make that work:

• Open formats and open engines. A standard database dump opens in the fallback without conversion. Many managed services at the large providers already run open-source engines such as PostgreSQL and Kubernetes; staying on them, with logical backups kept elsewhere, is a cheap first step.
• Backups outside the failing provider. In London, data in the dark zone waited for its storage to recover. A copy encrypted under your own keys, in another failure domain, is what the fallback starts from. DORA Article 12(3) already requires restores on your own systems to use systems “physically and logically segregated from the source ICT system”.
• A runbook that has run. Who decides, in what order services come back, and how long each step took last time.

Open source does not keep the lights on. The London site had two complete power paths and still went dark. A server room can fail the same way, and a single on-premises site is one failure domain, not a fallback. A second site needs people who patch, watch and test it, and spreading proprietary services across two clouds doubles that work rather than removing it. What matters is that you choose the second failure domain, with software that runs there unchanged, and prove it with a restore on a date.

How Pilae fits

A tested exit needs software that runs in more than one place and someone who keeps the second place ready. Pilae operates open-source apps on your premises or on dedicated machines in Pilae Cloud, so a fallback in your exit plan runs in a failure domain you choose: the same software where the service already runs on open source, or an open-source replacement fed by scheduled exports where it does not.

• A tested fallback per critical provider. Our exit plan service gives each critical SaaS or cloud dependency a documented fallback on open-source or source-available apps you control, from a warm standby to a documented cold start, fed by scheduled exports in open formats. Every test leaves a dated record for your register and your auditors.
• Your premises first, a region you name second. On Business and Enterprise, apps run on your servers or in any of 10+ Pilae Cloud regions, with the region and data centre for every machine and backup named in your contract.
• Backups away from what they protect, under your keys. Backups are daily, encrypted on your machine before they leave and stored offsite, with the keys held by you. On the Enterprise plan, an engineer restores them every month and records the result in the console.
• Register and contract data in writing. For DORA, we deliver the provider, location and subcontractor data your register records, and the contract terms Article 30 lists, including exit and a transition period. For FINMA, your contract gives you, your audit firm and FINMA audit rights.
• Leaving Pilae is planned too. You receive your data, configuration and runbooks in open formats, so another operator or your own team can take over the same apps (exit plan).

Our plans and prices are on the pricing page. To find out what a tested exit would take for your critical providers, talk to an engineer: we go through the functions you run, where each would run if its provider failed, and how to prove it with a restore.

This post is general information, not legal advice. For the official texts, read Regulation (EU) 2022/2554 on EUR-Lex and FINMA Circular 2023/1.