The power failure that travelled from one cloud zone into British banking

Investigation · Critical infrastructure · Sources checked through 24 October 2026

At 6:53 a.m. on Tuesday, 20 October, an electrical supply interruption hits a London data-centre facility hosting part of Google Cloud. Seven minutes later, the battery systems keeping the equipment alive begin to run out. Diesel generators have failed to take over. According to Google’s preliminary incident report, both the primary and backup programmable controllers responsible for the automatic start and transfer sequence failed. A cloud availability zone drops offline. The disruption then reaches systems that have not lost power at all. S01

Across the British banking sector, the visible effects are immediate and familiar. Some Revolut customers have trouble signing in, paying by card, withdrawing cash and making transfers. Lloyds, Halifax and HSBC acknowledge interruptions to their digital services. Businesses in other industries and public services, including remote court hearings, also run into problems. Different customers and separate corporate structures turn out to share a dependency capable of interrupting them at the same time. S02 S14 S16

Google’s 22 October preliminary account offers a more revealing explanation than the early reports of a power outage. The initial electrical failure was followed by two documented forms of internal contagion: redirected workloads overwhelmed capacity in other availability zones, while control-plane operations kept waiting for information from components that had gone dark. Google’s principal service incident lasted six hours and ten minutes, from 7:00 a.m. to 1:10 p.m. British Summer Time. The report remains preliminary. A final investigation and corrective-action report has been promised. S01

Those findings take the story through three levels of infrastructure. One is the electrical plant and the automation meant to keep it running. Another is the region-wide network of computing, storage and control services. The third is the banking application that people actually use. Google has begun to explain the first two. The most consequential questions about the third still require evidence from financial institutions and their supervisors.

Seven minutes at the electrical boundary

The electrical design of a large data centre is intended to survive a loss of external power. Uninterruptible power supplies, or UPS systems, use batteries to bridge the interruption. Emergency generators are expected to start and assume the electrical load before those batteries are exhausted. Switching between those sources requires more than spare machinery: controllers must issue the correct commands, manage the transfer and respect safety interlocks. S01

At 6:53 a.m. BST, Google’s account places a grid disruption at the facility hosting europe-west2-b, one of the zones in its London region. The UPS banks immediately carry the facility load. The programmable logic controllers (PLCs) responsible for the generator start and transfer sequence fail to complete it. Google expressly includes both the primary and backup PLCs in that account. Beginning at 7:00 a.m., the batteries become depleted and physical hosts, storage and network equipment start losing power. S01

Method and limits

All times are BST, as provided or converted in Google’s 22 October account. The seven-minute figure is the interval between the reported power event and the beginning of depletion, not a measured or guaranteed UPS autonomy. The physical state of the diesel generators, the identity of the colocation operator and any common underlying cause of the two PLC failures have not been disclosed.

The distinction matters because a generator that exists and is maintained is still useless if the control sequence cannot bring it into service. Genuine redundancy depends on the devices, commands, shared dependencies and test procedures operating together under abnormal conditions. The report establishes that two control paths failed. It has yet to explain why both failed. A shared configuration problem or common control dependency would be worth investigating, but either would remain a hypothesis until supported by the final technical findings. S01

Power supply at the site was stabilised within an hour, Google says, with the generator controllers subsequently reset and tested. Restoring cloud services took considerably longer. Engineers first isolated failed components, adjusted routing and capacity allocations, restarted infrastructure and gradually readmitted traffic once service and storage integrity had been checked. A power event, a cloud platform incident and a customer’s application outage consequently have different timelines. S01

Google told Reuters that the event occurred at a third-party facility within its London cloud region. The documents reviewed for this investigation do not identify that facility’s operator through a confirmed primary record or disclose the contracts governing electrical operations there. Nor does the facility’s third-party status, on its own, establish liability for the outage. The distinction between where equipment is located, who operates it and who owes service commitments to customers matters if damages or regulatory findings eventually follow. S04

Load shifts and dependencies across zones

Google’s London region, europe-west2, consists of multiple availability zones. These are separately organised collections of computing infrastructure within a region, allowing customers to place workloads in different locations. Regional services, replicated databases and multi-zone deployment strategies are intended to reduce the impact of losing a single zone. Their effectiveness still depends on the configuration of each product, the ability to take over work elsewhere and the capacity reserved for that purpose. S01 S10

Once zone B became unreachable, the first part of Google’s reported sequence was conventional failover. Regional traffic systems and client applications redirected work to the surviving europe-west2-a and europe-west2-c zones. They also had to handle high-availability database failovers. Available computing capacity could not absorb all the sudden demand seamlessly. Admission queues grew, database transitions took longer, and customers experienced intermittent HTTP 500 and 503 responses: server-side errors and temporary service unavailability. S01

The second propagation path was less visible. A cloud provider has a control plane, the software layer that schedules jobs, validates configurations and consults service metadata. Google’s preliminary report says some regional control-plane calls were synchronous and still required responses from metadata or catalogue components in the unavailable zone. The requesting service waited until the call timed out. That made job submission and API operations slow or unreliable even when the machines performing the work were physically located in powered zones. S01

Method and limits

Conceptual reconstruction from Google’s preliminary technical report dated 22 October. Zones A and C are named by Google as places where otherwise unaffected workloads could experience degraded service. Arrow width and block area do not represent measured workload volumes or bank-specific network paths.

There are two different forms of resilience here. Physical redundancy supplies alternative machines and places to run the workload. Functional resilience ensures that those alternatives also have sufficient capacity, access to the necessary data and functioning authorisation, scheduling and control services. A second data hall that lacks one of those conditions may contribute far less during an emergency than its existence suggests.

Several multi-zone failovers worked during the incident. Google says data services including Cloud SQL, AlloyDB and Bigtable transferred operations to surviving zones. The failure lay in the combination of abruptly concentrated workload, finite spare resources and cross-zone dependencies. Google’s own disaster-recovery guidance treats rapid recovery as an explicit architecture decision, requiring service-specific automation and, for the strictest recovery objectives, costly resources already running or ready to take over. S01 S10

Separate recovery timelines for Google and its customers

The earliest Google service notices referred to 7:08 a.m. BST as the start of the incident. The preliminary report now separates three events: the electrical interruption at 6:53 a.m., customer-facing degradation counted from 7:00 a.m., and automated detection by Google’s monitoring systems at 7:08 a.m. Each timestamp identifies a different stage of the incident. S01

According to Google, the first phase of broadly affected core services had largely recovered by 12:29 p.m. New virtual-machine creation resumed at 12:46 p.m. At 1:10 p.m., more than 99% of Compute Engine virtual machines were healthy, and the vast majority of customer workloads were reported as recovered. Google posted the incident-closure notice at 3:03 p.m., after further work on a small number of residual cases. The 99% figure is a measure of virtual-machine health for one class of infrastructure. It is not an estimate of the share of banks, payments or consumers back online. S01

Method and scope

Dates and clock times from Google’s 22 October preliminary report. The main bar covers 7:00 to 13:10 BST, 370 minutes. The shorter tail reaches the 15:03 status closure. Four separately spaced event cards provide context; this is not a minute-by-minute availability series for any bank.

Revolut’s service status provides a striking comparison. At 6:00 p.m. BST, nearly five hours after Google’s reported recovery of the vast majority of workloads, Reuters found that only six of the twenty-seven service categories listed on Revolut’s UK status page were operational. Card payments, transfers, ATM withdrawals and several other functions were still reporting problems. In an update timestamped 8:14 p.m. Paris time, equivalent to 7:14 p.m. BST, MoneyVox reported that all Revolut services were operational. That is the time of the published observation; the precise restoration minute remains to be established. S03 S12

The 6/27 measure describes categories on a particular UK status page at a particular time. Those categories cover different functions and transaction volumes. Measuring the number of affected customers would require separate data. Similarly, Google’s six-hour-ten-minute figure refers to its own main platform incident. A downstream bank can take longer to process backlogs, restore service links or verify transaction states after infrastructure returns. The public record does not establish the relative contribution of those activities to Revolut’s specific recovery.

The banks’ reported service disruptions

There is a significant difference between retaining a customer’s money safely and giving that customer the ability to use it. A banking app outage may leave account balances and underlying records intact while preventing an ordinary payment, cash withdrawal or transfer. Revolut stated that customer funds and data remained safe during the incident. That reassurance is attributable to the bank; it is not an independent measurement of failed transactions, delayed access or the financial harm suffered by users. S02 S04

Lloyds Banking Group, including Halifax, acknowledged difficulties with digital banking. HSBC also confirmed that customers were having trouble accessing services. The level of detail in the three sets of public reports varies substantially. Revolut’s status page exposed numerous individual functions, while the accounts available for Lloyds and HSBC mainly describe online access and other digital difficulties. Treating these as three identical outages would be misleading. S02 S14

Method and limits

Reuters and AP reporting dated 20–21 October, drawing on the banks’ announcements and public status indicators. Service scopes are not directly comparable. No system-level diagrams, complete failover configurations or per-bank impact assessments were publicly available in the reviewed sources.

Revolut explicitly attributed its disruption to the Google Cloud incident. Reuters and AP also reported Lloyds/Halifax and HSBC difficulties during the episode; the reproduced bank statements confirm service problems, while the precise technical chain remains to be documented. This makes correlated operational exposure a relevant line of inquiry: a shared dependency can affect several institutions at once. Tracing each bank’s path would require its product choices, workload locations, spare capacity and any intermediary providers. S02 S04 S12 S14

Those unknowns are important in a security-sensitive industry. A bank might rely on a provider for an API gateway, an analytics pipeline, a payment-support system or a component serving its mobile app, among other possibilities. A similar customer symptom does not establish an identical internal architecture. We have found no public evidence that would justify assigning any one of those paths to Revolut, Lloyds or HSBC. Nor does the technical report describe a cyberattack, intrusion or data theft as the cause. It describes a power-grid interruption, failed electrical control automation and the platform’s subsequent response. S01

The effects were not confined to finance. Remote court hearings in the UK were affected through video-service interruptions, while businesses in property, logistics and other digital sectors also reported problems. The lesson is in the diversity of those functions. They may not have any direct commercial relationship with one another yet still depend on parts of the same external computing infrastructure. Not every outage report collected by internet-status aggregators was causally linked to Google, however. Unverified reports should not be counted as established consequences of this event. S02 S14 S16

Twelve days earlier, Britain’s financial sector rehearsed a global cloud outage

On 8 October, the Cross-Market Operational Resilience Group, co-chaired by the Bank of England and UK Finance, ran its biennial SIMEX26 exercise. This year’s scenario was a worldwide cloud-services disruption. The central bank’s 9 October announcement says 38 major banks and systemically important market-infrastructure operators participated alongside the financial authorities. The exercise was designed to rehearse collective crisis management and the financial sector’s response mechanisms. S05

The timing is extraordinary, though the comparison requires care. SIMEX26 modelled a global hypothetical cloud outage. The 20 October event began at a particular physical location in London and propagated across part of Google’s regional architecture and its customers. The 38 institutions are the exercise participants, not a count of banks affected by the real outage. The Bank of England did not publish firm-by-firm scores or a quantified account of successful recovery in its news release. S05

Method and scope

Timeline is ordered, not to temporal scale. Four designations took effect on 13 July; the 38-institution exercise took place on 8 October; the outage and Parliamentary letter followed on 20 October; Google’s preliminary report was published on 22 October. The requested response dates do not guarantee publication or determine the regulators’ findings.

The exercise documents collective preparation for a defined scenario. Assessing its value during the real incident would require the functions tested, each participant’s procedures and the simulation results. The announcement leaves that firm-level assessment open. The 20 October review should establish which plans were activated, how quickly they worked and which essential customer services were maintained.

New supervisory powers, an unexpectedly prompt test

Since 13 July 2026, Google Cloud EMEA Limited has been one of four technology companies designated as a Critical Third Party by HM Treasury. The others are entities belonging to Amazon Web Services, Microsoft and Oracle. Britain’s Bank of England, Prudential Regulation Authority and Financial Conduct Authority now oversee designated firms jointly in respect of services whose failure could damage financial stability or confidence in the financial system. The regulatory framework came into effect in January 2025, but these first individual designations only took effect in July 2026. S06 S15

The European Union has a separate framework. DORA, the Digital Operational Resilience Act, has applied since 17 January 2025, requiring financial firms to manage information-technology risk and creating an oversight mechanism for critical ICT service providers. In November 2025, the European Supervisory Authorities published a list of 19 critical providers, including Google Cloud EMEA Limited. Their assessment draws, among other things, on contractual-dependency registers, how widely important functions depend on the provider, and the practical possibility of replacing its services. British and EU supervision may concern the same corporate provider; they are not the same legal process. S08 S09

Reuters reported on 21 October that the European Banking Authority had contacted Google Cloud to obtain information and assess possible effects on EU financial entities. The FCA likewise confirmed engagement with Google. These exchanges begin an information-gathering process. Conclusions on compliance and any further action remain to be issued. S04

In Britain, the parliamentary response was unusually detailed. The Treasury Committee’s chair, Meg Hillier, wrote on 20 October to the governor of the Bank of England and the head of the FCA. Her letter asks when the authorities were alerted, how many financial firms and consumers were affected, what services failed, how long outages lasted, how the supervisors reacted and what customer losses or remedies were identified. She requested an initial reply by 4 November 2026 and a full response by 20 January 2027. Those are requested deadlines, not published findings. S07

Regulators also hold the banks responsible for their own continuity. British prudential guidance requires relevant institutions to identify important business services, establish impact tolerances for disruption and demonstrate that these limits can be respected in severe but plausible circumstances. The obligation remains with the regulated business even when a third party supplies part of the service. S11

That framework does not justify a compliance verdict against any of the affected banks today. Assessing a breach would require each firm’s designated important services, its approved tolerance, evidence of the actual interruption, the availability of alternative channels and the effect on customers. We have not found those records in the public documentation reviewed. A headline announcing that an app is operational again tells us relatively little about the losses or disruption suffered before it returned.

Recovery across cloud providers

A second supplier can seem an appealing response to a shared dependency. That can reduce exposure to some shared failures, but only where the relevant application is genuinely portable and ready to run on the alternative. A second provider adds limited protection if data has not been replicated, authentication still depends on the first provider, essential interfaces have changed or the failover process has never been exercised. S10

Two recovery measures capture the trade-off. RTO, the recovery time objective, is the time an organisation aims to take before a service is working again. RPO, the recovery point objective, sets the maximum acceptable data loss, usually expressed as the interval between the last recoverable point and the incident. Payments bring a particularly demanding integrity problem: fast recovery is of little comfort if the system cannot reliably establish whether an instruction was accepted, posted or settled. Google’s disaster-recovery guidance explains why replication method, database behaviour and failover configuration affect both RTO and RPO. S10

Running actively across multiple regions or providers has recurring costs. It requires live spare infrastructure, data replication, rules for handling conflicting updates, monitoring and trained people who can execute the plans. Complexity can itself create incidents. That is why a sensible resilience strategy can combine multi-zone deployment, selective regional standby capacity and alternative procedures for essential services, rather than pursuing identical duplication everywhere. The adequacy of that approach depends on the damage that a given disruption could cause and the likelihood of the scenarios being covered. S10 S11

There is a serious counterargument to treating large cloud providers as inherently fragile. Shared infrastructure can offer sophisticated monitoring, engineering talent, redundancy and restoration capabilities that many individually operated data centres could not match. The 20 October record offers no fair, comparable incident-rate dataset with which to judge those models against each other. What it does establish is the route by which a local technical failure can become a simultaneous operational problem for otherwise unrelated businesses.

This dependency extends our investigation into the invisible suppliers of European banking risk. The CDK and Synnovis cases trace disruption through a shared provider, while the cost of a faster recovery examines resources and tests committed before a crisis. Their causes differ; each investigation follows a service and its dependencies through specific records.

Records needed to measure the damage

Four sets of records would resolve much of the remaining uncertainty. Google’s final root-cause report should explain the concurrent failure of both PLC paths, the testing history of the electrical transfer sequence and the division of responsibilities at the third-party facility. Bank-level impact reports are needed to identify affected functions, start and recovery times, failed or delayed transactions and alternative customer channels. Third, the actual failover tests and capacity assumptions of relevant workloads would show whether resilience plans were proportionate to their risks. Finally, supervisory documents should clarify notifications, obligations, actual consumer harm and remediation. These elements were not available as a complete, verifiable set by 24 October. S01 S04 S07

A credible loss estimate needs bank-level evidence of failed or delayed transactions, their value and any subsequent completion through another channel. Total customer counts and Google’s incident duration measure different things. The Treasury Committee has explicitly asked the financial authorities to establish the missing measures. S07

The incident still supports a substantial conclusion. London’s Google Cloud region had several zones and operational failover mechanisms, some of which successfully moved workloads. Yet demand shifts and cross-zone control dependencies carried disruption beyond the electrically failed site. The banks then experienced different visible effects, with at least one significant customer-facing recovery extending well beyond the main cloud incident. The next answers will come from engineering records, contractual arrangements and evidence of how the institutions’ operational tolerances worked when they were needed. S01 S03 S11

Sources and verification scope

Sources reviewed through 24 October 2026. Technical incident times are BST (UTC+1). References to Paris time are marked CEST (UTC+2). Provider statements are attributed as such, and the press is used principally to cross-check customer-facing impacts. Google’s preliminary report is not an independently audited final finding.

1. [S01] Google Cloud, preliminary incident report.Published 22 October 2026; event on 20 October, 07:00–13:10 BST. Details the generator-controller failures, regional propagation and recovery. Final report pending.
2. [S02] Reuters, Anhata Rooprai, UK Google Cloud outage.Published 20 October 2026. Reports banking and other public-service disruption, with caveats about unverified associations.
3. [S03] Reuters, Revolut recovery status.Published 20 October 2026. Snapshot at 17:00 UTC: six of twenty-seven UK service categories marked operational.
4. [S04] Reuters, Phoebe Seers and Elizabeth Howcroft, regulators and Google.Published 21 October 2026. Reports EBA and FCA enquiries; attributes the third-party facility description to Google.
5. [S05] Bank of England, SIMEX26 press release.Published 9 October 2026; exercise held on 8 October. The 38 are simulation participants, not banks affected by the later outage.
6. [S06] Financial Conduct Authority, critical-third-party oversight guidance.Published 10 July 2026. Initial designations effective 13 July; describes targeted supervision and firms’ continued responsibilities.
7. [S07] UK House of Commons Treasury Committee, signed letter from Meg Hillier.Dated 20 October 2026. Nine questions; initial response requested for 4 November 2026 and full response for 20 January 2027. Two-page letter.
8. [S08] ESMA / EBA / EIOPA, DORA critical-provider designations.Published 18 November 2025. Lists 19 designated providers, including Google Cloud EMEA Limited.
9. [S09] European Union, Regulation (EU) 2022/2554 (DORA).Dated 14 December 2022, applicable since 17 January 2025. Includes oversight of critical ICT third-party service providers.
10. [S10] Google Cloud, disaster-recovery architecture guidance.Updated 10 May 2024, accessed 24 October 2026. General recovery principles, distinct from the affected banks’ infrastructure.
11. [S11] Bank of England / PRA, SS1/21, operational resilience.Version published 11 March 2022, effective 31 March 2022. Important business services, impact tolerances and firms’ responsibilities (§§ 2.2, 3.1 and 4.5). Accessed 24 October 2026.
12. [S12] MoneyVox, Revolut disruption updates.Published 20 October 2026 at 13:19 CEST, updated 20:19 CEST, including a 20:14 CEST update observing all services operational; the exact restoration minute is unspecified.
13. [S13] Uptime Institute, Owen Rogers, independent analysis.October 2026. Discusses the preliminary technical findings and responsibility boundaries across colocation, cloud and customer operations.
14. [S14] Associated Press, banks and other services affected.Published 20 October 2026. Independent reporting on customer-visible disruption; no bank-by-bank infrastructure blueprint.
15. [S15] HM Treasury, first four UK critical-provider designations.Published 10 July 2026; effective 13 July 2026.
16. [S16] Law Society Gazette, Matilda Battersby, remote court hearings.Published 20 October 2026 at 14:03 BST. Reproduces HM Courts & Tribunals Service’s notice that Cloud Video Platform was disrupted; does not disclose its back-end architecture.