One Zone Lost Power. Revolut Lost the Day. Google Closed Its Incident While Revolut Was Still Down.

1:08 AM Central

At 1:08 AM Central on Tuesday, October 20, 2026, it was 7:08 in the morning in London, and the commute was starting. That is the minute Google's own incident record gives for the start of the trouble in europe-west2, the Google Cloud region that serves London. Within the hour, people standing at ticket barriers, coffee counters and petrol pumps in Britain and Ireland were tapping a Revolut card and watching it fail. The app would not open. Transfers would not send. Cash machines would not pay out. Downdetector reports for Revolut spiked between 7 and 8 AM, per The Irish Times. Revolut serves 3.4 million customers in Ireland alone.

Google posted nothing on its status page until 3:35 AM Central. It did not say what had happened until 6:12 AM. It marked the incident "AVAILABLE" at 9:03 AM, with a note that the problem was "believed to be affecting currently a very small number of customers" and that "No further updates will be provided here." At 11:00 AM Central, two hours after that note, The Guardian checked Revolut's status page and found only 6 of its 27 listed services working. Revolut's statement that the issue "has now been fixed" was in BleepingComputer's story by its 12:52 PM Central update.

That is the outage as customers lived it. What follows is longer, because the outage is not the story. The story is that Google Cloud EMEA Limited had been under the UK's Critical Third Parties oversight regime for 99 days, since July 13, when one of its London zones lost power. It is that Google's own architecture documents call a zone "a single failure domain" and tell financial firms that regulators treat losing a second zone as plausible. It is that Revolut's own 2025 annual report, published in April, names the class of event, a power or cooling failure at a cloud provider, as a risk that "could have a severe impact," though it framed that risk as climate-driven. It is that the same London region has had serious facility failures before, cooling in 2022 and power at a London point of presence in 2024, both with effects beyond a single facility, and the post-mortems are still public. And it is that Revolut, which received preliminary conditional approval for a U.S. national bank charter seven weeks ago, now has a live answer to the question every bank regulator asks first: what happens to customers when the cloud goes dark.

What we verified, and two things the first reports got wrong

Cloudskope began its own checks at 2:00 AM Central on October 21. Everything below was done with ordinary public requests: Google's public status feed, public DNS, published IP ranges and Revolut's public pages. No credentials, no scanning.

Google's incident record, in full

At 2:00 AM Central we pulled the machine-readable feed behind Google Cloud's Service Health dashboard (status.cloud.google.com/incidents.json, 205,148 bytes, SHA-256 beginning 33782086). The London incident is recorded as Xs2XTHzAVC9YnafnPyzj. Its fields say the incident began at 06:08 UTC, the record was created at 08:35:37 UTC, the incident ended at 14:00 UTC, severity was "medium," and the affected location was London (europe-west2). It carries seven updates and lists 38 affected products, among them Compute Engine, Persistent Disk, Google Kubernetes Engine, Cloud SQL, Cloud Spanner, Cloud Storage, Pub/Sub, Cloud Load Balancing, Cloud NAT, Virtual Private Cloud, Apigee and BigQuery.

That list matters. Early coverage, including The Register's, listed seven affected products. Google's final record lists 38, the same number a Keele University academic estimated to The Register. We could not establish when the list grew; the Internet Archive refused our requests for earlier snapshots with HTTP 429 errors. But a reader comparing early coverage to the final record should know the two do not match, and that the larger number is Google's own.

One zone, per Google

The Stack wrote on Tuesday that the incident "seems to have affected all" three zones in the London region. Google's record does not say that. Its fourth update reads: "Google Cloud services are unavailable in europe-west2-b zone; some services in europe-west2 region may experience elevated errors and intermittent network issues." One zone down. The rest of the region degraded. That distinction is the heart of this piece, so we state it precisely: Google says one zone failed and the effects reached beyond it.

Reports that give the start as "0608 GMT" are right only if read as UTC. Google's record says 23:08 PDT on Monday, which is 06:08 UTC and 07:08 British Summer Time. The UK had not yet changed its clocks, so the trouble began just after 7 AM for people in London.

Where Revolut's front door lives

At 2:00 AM Central we resolved Revolut's public hostnames over DNS-over-HTTPS. The website, the web app, single sign-on, Revolut Business, the merchant site and the open-banking portal all sit behind Cloudflare. Three hosts do not. api.revolut.com resolves to 35.201.77.50, oba-auth.revolut.com to 34.54.167.198, and pay.revolut.com to 34.149.61.165. Google's own published list of Google Cloud address ranges, generated at 19:10 UTC on October 20, places all three in Google Cloud blocks with scope "global." RIPEstat shows 35.201.77.50 announced by AS396982, GOOGLE-CLOUD-PLATFORM. A plain HEAD request to api.revolut.com and pay.revolut.com at 2:00 AM Central returned the response header "via: 1.1 google."

Translated: Revolut's API and payment front ends terminate on Google Cloud's global external load balancer. "Global" here describes the anycast front door, which answers from Google's edge everywhere. It does not tell us which region runs the services behind it. We infer, and label it as inference, that the services Revolut lost on Tuesday ran at least in part in europe-west2. Revolut's own evening statement makes the same link: "Due to a recent Google Cloud outage, customers may have experienced temporary service disruption on the Revolut app today."

What Revolut's status page says now

At 2:12 AM Central on October 21 we read Revolut's public system-status page (the en-US version; regional versions may list different services). It said "All systems are operational." It listed 25 services. It carried no incident history and no record that October 20 happened. During the outage, BleepingComputer counted 28 services marked partially unavailable on the same page, and TheJournal.ie counted 31. A customer arriving today to understand what went wrong yesterday would find nothing.

What we could not verify

We could not verify that Lloyds, Halifax or HSBC were affected because of Google. Customers reported problems at all three on Tuesday, per The Guardian, and Lloyds said the "root issues have been resolved." The Telegraph also named Bank of Scotland and NatWest. None of them named Google. When we resolved their public hostnames, Lloyds and Halifax sat behind Akamai and HSBC behind AWS CloudFront address space, which hides the origin. We treat them as reported disruptions with an unconfirmed cause. We could not verify a report that Revolut's U.S. status page showed 28 services partially unavailable at 6:46 AM Eastern; that comes from a single outlet. And we could not learn what the power event was, because Google has not said.

Google's first word came 147 minutes after the lights went out

Read Google's record the way a regulator will, one update at a time.

The first update was posted at 08:35:37 UTC, which was 3:35 AM Central and 9:35 AM in London. That is 2 hours and 27 minutes after the start time Google itself later recorded. By then Revolut customers had been failing at tills for more than an hour and Downdetector had been charting it. The update said: "We are experiencing an issue with multiple services in europe-west2 beginning on Monday, 2026-10-19 23:08 PDT. Our engineering team continues to investigate the issue." Symptoms: "elevated errors and intermittent network failures." Workaround: "None for now."

Read it for what it does not contain. No zone. No cause. No list of what was down in the update text. A customer's engineers reading it at 9:35 AM London time knew the region was unwell and nothing about which failure domain to route away from.

The second update, 49 minutes later, added one sentence that matters: "If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region)." That is Google telling customers, in the middle of the incident, that the remedy is to be somewhere else. It is also the most important sentence in the record, and we will come back to it.

The cause arrived five hours in, in thirteen words

At 11:12:42 UTC, 6:12 AM Central, the fourth update said: "Due to a power event we had suffered an outage within europe-west2-b zone. The power event is mitigated." Five hours and four minutes after the start. That is all Google has said about cause. The record does not say whether the event was a loss of utility supply, a switchgear or transformer fault, an uninterruptible power supply failure, a generator that did not start, or a fault in a power distribution unit inside the hall. Each of those is a different failure with a different lesson, and Google has had post-mortems for most of them before.

The fifth update, at 11:58 UTC, said Google was "prioritizing the recovery of existing workloads" and that "Customers may not be able to yet create new workloads." Hold that sentence too. A customer whose resilience plan depended on spinning up fresh capacity in London to replace what was lost in zone b was told, nearly six hours in, that it might not be able to.

The sixth update reported "recovery of services for most workloads in europe-west2 as of Tuesday, 2026-10-20 05:10 PDT," which is 12:10 UTC.

The incident closed with "a very small number of customers" still down

The seventh and final update, at 14:03:41 UTC, 9:03 AM Central and 3:03 PM in London, changed the status to "AVAILABLE." Its text: "The issue with impacted GCP products has been mitigated for most of the customers and it is believed to be affecting currently a very small number of customers and our Engineering Team is working on it. If you have questions or are impacted, please open a case with the Support Team and we will work with you until this issue is resolved. No further updates will be provided here. We will publish an analysis of this incident once we have completed our internal investigation."

Two hours later, at 5:00 PM London time, The Guardian found 6 of Revolut's 27 services working. The video system used to attend court hearings remotely across England and Wales failed to work throughout the morning, per The Guardian, which gave no cause. Revolut's restoration statement came in the evening. The public record does not tell us whether Revolut's long afternoon was Google's residual problem, Revolut's own recovery (restarting services, draining queues, reconciling card authorizations), or both. Google's record does not distinguish. Revolut has not said.

What the record does show is a gap between two surfaces. On Google's, the incident was over at 3:03 PM London time and anyone still affected should open a support case. On Revolut's, two hours later, 21 of 27 services were still not working. Neither surface explains the other. Google's UK regulators require a Critical Third Party to "maintain open, timely communication with regulators and the firms that rely on them, particularly during major incidents." Ninety-nine days into that oversight, the gap between those two pages is the finding.

Revolut wrote this risk down in April

Revolut Group Holdings published its 2025 annual report in April 2026. The PDF's creation date is April 21. Cloudskope downloaded it at 2:11 AM Central on October 21 (208 pages, SHA-256 beginning 969dd74a) and read the risk sections against Tuesday.

Page 16 sets the scale: "Our team provides financial services to 69.1 million customers worldwide, including 68.3 million retail customers and over 750,000 business customers, across 39 countries (as of December 2025)." Revolut now tells reporters it has more than 80 million.

Page 42 names the provider: "we partner with Google Cloud as our data services provider." That sentence sits in the carbon section, not the risk section. The relationship itself is no secret. In September 2025 Revolut announced it was deepening its partnership with Google Cloud, "leveraging Google Cloud's secure, scalable infrastructure to power its rapidly growing global systems," on the way to 100 million customers.

Page 49 names the failure. In the climate-risk discussion, Revolut writes that its "highest exposure to physical climate risk is through Third party vendors and data centres," and then: "Any operational disruption to power supplies or cooling systems at cloud service providers could have a severe impact on Revolut's technological infrastructure."

Power supply. Cloud service provider. Severe impact. Revolut framed it as a climate risk, and Google has not said what caused Tuesday's power event, so we do not suggest weather had anything to do with it. But the class of event that hit Revolut on Tuesday is on page 49, six months in advance, in the company's own words.

Page 61 adds that disruptions may be caused by "matters outside of Revolut's control, such as a cyber-attack or wider telecommunications or power failure," and that Revolut is "actively managing concentration risk with third parties through diversifying our suppliers of third party services and by building solutions to a number of key processes in-house." It says "Concentration risk analysis is done regularly across third parties and outsourcing arrangements."

Page 63 lists the scenarios Revolut's Black Swan framework evaluates. The first: "Critical Infrastructure Collapse: A simultaneous, long-duration failure of multiple critical third-party infrastructure providers (e.g., cloud or internet services) globally."

Pages 78 and 81 record that the board risk committee ran deep-dive reviews of Black Swan scenarios "including the potential impact of cloud-provider outages" and reviewed scenarios "such as major cloud provider outages."

Page 87 is the one a supervisor will underline. The board "was also kept updated on its business continuity arrangements invoked by Severity 3 incidents involving cloud provider outages, the power blackout on the Iberian peninsula on 28 April 2025 and geo-political events." It also "reviewed and approved the outputs of its supplier concentration risk assessment."

So the board had seen cloud provider outages during 2025 that invoked business continuity arrangements. It had seen a regional power blackout. It had approved a concentration assessment. It had modeled a long-duration collapse of multiple cloud providers at once, globally.

Now read what the report does not contain. It does not name the Google Cloud regions or zones Revolut runs in. It does not say whether its important business services, the term the Prudential Regulation Authority uses for the services whose disruption would harm customers or markets, are deployed across more than one zone or more than one region. It does not give the impact tolerances, the maximum tolerable disruption Revolut set for those services under PRA rules. None of that is unusual for an annual report. But the scenario Revolut modeled most dramatically, several providers failing at once, worldwide, was far worse than what happened. What happened was a power event in one zone, in one city, at one provider, for part of one morning. It was enough.

For hours, Revolut said little beyond "money and data are safe"

Revolut's first public words, on X and to reporters, were these: "We are currently experiencing a service disruption affecting multiple services." And: "We can confirm that all our customers' money and data are safe." TheJournal.ie quoted a further line: "Our engineering team is actively working to restore full service as quickly as possible." Revolut also said it had been working to fix the issue since it was identified that morning, and apologised "to anyone affected and for any inconvenience caused," per The Irish Times.

Read them against what customers needed. No cause. No estimate. No word on whether cards would work at a till in the next hour, whether a payment already sent would arrive, whether direct debits would bounce, or whether customers should carry another card. Reuters attributed the link to Google to "a person familiar with the matter." Revolut did not name Google itself until the evening: "Due to a recent Google Cloud outage, customers may have experienced temporary service disruption on the Revolut app today. The issue has now been fixed, and services are now restored."

"May have experienced." Six of 27 services were working at 5 PM. Customers did not may-have-experienced anything.

The reassurance about money and data is accurate as far as anyone knows, and it is the right first sentence for a bank. Nobody has suggested data was lost or funds misdirected. But it answers the question customers were not asking. Their money was safe. They could not reach it.

A zone is a single failure domain. Google says so.

Google Cloud divides each region into zones, and each zone into physical facilities with their own power and cooling. The design promise is in Google's own documentation, under Geography and regions: "Zones should be considered a single failure domain within a region." A region "consists of three or more zones housed in three or more physical data centers." Google's reliability guide continues: "A failure in one zone usually does not affect the resources in the other zones in the region." Google's Compute Engine documentation adds: "Putting resources in different regions provides an even higher degree of failure independence."

For banks specifically, Google publishes a financial-services perspective in its Well-Architected Framework, last updated July 28, 2025. It is blunt. "For critical financial services applications, we recommend that you use a multi-region topology." It warns that "most jurisdictions consider a severe disruption to a second zone to be a plausible consequence." And it says: "In each region, leverage three zones rather than two."

Lay that guidance over Tuesday. Google says one zone failed. Google's own banking guidance recommends a multi-region topology with three zones per region, and notes that most regulators treat losing a second zone as plausible. A financial service that went down for most of a working day when one zone lost power was not, on Tuesday, operating the way Google tells banks to arrange it. Either its affected components lived in a single zone, or they depended on regional components that failed with the zone, or its failover to another region did not work or did not exist.

We cannot say which. That is a hypothesis, and only Revolut's architecture diagrams and incident timeline can settle it. But every branch ends in the same place. The fix was written down, by the provider, for this industry, in guidance current since at least July 2025.

London's facilities have failed before, and the failures spread

Google's own post-mortems show that the clean line between a zone and its region does not always hold, and that it has failed in this region.

On July 19, 2022, during the British heatwave, "One of the data centers that hosts zone europe-west2-a could not maintain a safe operating temperature," after redundant cooling systems failed together. To protect equipment, Google powered down machines. Then, in its words, "we inadvertently modified traffic routing for internal services to avoid all three zones in the europe-west2 region." Customers of Cloud Storage "were unable to access any replica for a number of storage objects," and "ReadObject availability for buckets located in europe-west2 dropped to approximately 86%." The incident lasted "a total of 18 hours, 23 minutes." One zone's cooling failure became a regional storage outage through Google's own traffic engineering.

On August 12, 2024, in the same region, a substation switchgear failure meant "primary and backup power feeds were both lost" at a partner-maintained Google point of presence, a network facility rather than a zone, and "stored or generated on-site emergency power did not carry loads," per Google's incident report. It lasted a little over two hours and affected regional services, including load balancing.

On October 23 and 24, 2024, in Frankfurt, "an electrical arc flash occurred in one of the europe-west3-c zone's power distribution units." The outage lasted about seven hours and 39 minutes.

In April 2023, in Paris, water from a cooling system "entered an associated uninterruptible power supply (UPS) room, and led to a fire," and "the control plane services for many Google Cloud services were interrupted in europe-west9," the whole region.

Four Google power or cooling events in Europe in a little over two years, from July 2022 to October 2024, two of them in London, and at least three with documented effects beyond the facility where they started. A bank architect who read those reports would not have treated a single London zone, or a single London region, as safe to depend on alone. Google's own customers were told, in Google's own words, where the edges were.

One year to the day

October 20 is becoming an anniversary. On October 20, 2025, Amazon Web Services suffered a disruption across many services in its us-east-1 region for most of a day. Its post-event summary traced the root cause to "a latent race condition in the DynamoDB DNS management system" and put the event at roughly 14 and a half hours, from 11:48 PM Pacific on October 19 to 2:20 PM on October 20. In the UK, Lloyds, Halifax, Bank of Scotland and HMRC were among the services hit, per Mortgage Introducer.

That same day, the chair of the House of Commons Treasury Committee, Dame Meg Hillier, wrote to the Economic Secretary to the Treasury. The UK's Critical Third Parties rules, she noted, "will only apply in practice to each CTP from the point it is designated by the Treasury," and as far as the Committee was aware "no firm has yet been designated as a CTP." The rules had been in force since January 1, 2025. Nobody was covered by them.

The Treasury fixed that on July 10, 2026, when it announced four designations. One was Google Cloud EMEA Limited. Oversight began on Monday, July 13. Ninety-nine days later, the first major incident at a designated provider that we are aware of took a bank offline for most of a day. On the day of the outage, the same committee chair wrote again, this time to the Governor of the Bank of England and the Chief Executive of the Financial Conduct Authority. The second paragraph of her letter begins with the date of designation, and her first question is: "When were the authorities first alerted to a problem at Google Cloud, and by whom?"

The first test of the Critical Third Parties regime came 99 days in

The UK regime exists for exactly this morning. The Financial Services and Markets Act 2023 gave HM Treasury the power to designate providers whose failure could threaten the stability of, or confidence in, the UK financial system, and gave the Bank of England, the PRA and the FCA powers to oversee them. The regulators' final rules, PRA PS16/24 and FCA PS24/16, took effect on January 1, 2025. When they were published in November 2024, the PRA noted, "HMT had not designated any CTPs."

The Bank of England's release of July 10, 2026 names the first four: "Amazon Web Services EMEA SARL," "Google Cloud EMEA Limited," "Microsoft Ireland Operations Ltd" and "Oracle Corporation UK Limited." It says "Designation under this regime is not the same as authorisation by the regulators" and that "Oversight is limited to the resilience of the services they provide to UK financial firms." It says CTPs must "identify and manage risks to their critical services effectively" and "maintain open, timely communication with regulators and the firms that rely on them, particularly during major incidents."

The Bank's Financial Policy Committee welcomed the designations at its September 25 meeting, recording that "The CTP regime will support a more resilient environment for firms to operate in." In a discussion of AI-enabled cyber risk, its July Financial Stability Report had already warned that "important business services depend heavily on complex digital infrastructure and common third-party technology" and that, where many firms share a provider, "Suppliers may be unable to support all affected clients at the same time."

On Tuesday, the FCA told The Telegraph: "We are aware of an incident affecting services provided by Google" and said it was "engaging with them and affected firms to understand the impact." It added: "People need to be able to access their money and make payments," and "we expect firms to fix issues quickly, keep their customers informed and ensure no one is left out of pocket." The Bank of England and the PRA declined to comment, per the same report. John Glen MP, a former Conservative minister and a member of the Treasury Committee, told the paper: "Where three companies maintain cloud storage for 75-80pc of the market, the public need reassurance" that regulators can intervene.

Dame Meg Hillier's letter of October 20, 2026 states the premise plainly: "Google Cloud EMEA Limited has been a designated Critical Third Party since 13 July 2026." She asks nine questions. Among them: "What caused the incident at Google Cloud which led to service issues at UK financial firms?" "How many UK financial services companies were affected by the issues at Google Cloud?" "What lessons have the authorities learnt about the operation of the Critical Third Party regime from this incident?" "What lessons should regulated financial firms (rather than Critical Third Parties) take from this incident when thinking about their own operational resilience?" And: "How many UK consumers were affected by this incident, which services were disrupted, and for how long?" She wants an initial answer by Wednesday, November 4, and a full one by January 20, 2027.

The eighth question is the one that matters most for every bank board, in the UK or anywhere else. The regime oversees the provider. It does not move the obligation. Under PRA Supervisory Statement SS1/21, a firm must set an impact tolerance for each important business service, defined as "the maximum tolerable level of disruption," and must be able to stay within it "no later than Monday 31 March 2025." PRA SS2/21 on outsourcing, updated in March 2026, recognises the benefit of distributing "data and applications across multiple, geographically dispersed availability zones and regions," and lists "concentration of outsourcing and other third party dependencies in a close geographical location" among the concentration risks firms must manage. Google, in its own announcement of its EU designation, said the same thing about Europe's regime: "CTPP oversight does not replace your own responsibilities under DORA."

Europe designated Google eleven months before the outage

The EU's Digital Operational Resilience Act has applied since January 17, 2025. On November 18, 2025, the European Supervisory Authorities published their first list of critical ICT third-party providers: 19 firms, including Google Cloud EMEA Limited, which Google said had been assigned "a dedicated Lead Overseer." Revolut holds its European banking licence in Lithuania. Euronews reported disruption for customers in the UK, Ireland, France, Spain and Japan, among other countries.

So the provider at the center of Tuesday was, on Tuesday, under direct resilience oversight in the UK for 99 days and in the EU for 336. We do not yet know what either overseer knew, when, or from whom. The Treasury Committee has asked. We found no public statement from Europe's Lead Overseer. Neither regime issued a formal public statement during the outage; the FCA commented to The Telegraph.

Why an American bank board should read this

Revolut is not only a European story. On September 2, 2026, the Office of the Comptroller of the Currency granted preliminary conditional approval for Revolut Bank US, National Association, of Stamford, Connecticut (Corporate Decision 1390). Among the conditions: a third-party risk management program, and a pre-opening review that includes vendor management and business resumption contingency plans. American Banker reported that Revolut serves roughly one million U.S. customers through partner banks. The bank still needs FDIC insurance and final OCC approval before it can open.

On Tuesday, a single outlet reported that Revolut's U.S. status page showed 28 services partially unavailable at 6:46 AM Eastern. We could not confirm it. If it holds, the outage reached U.S. customers through a London zone, which is itself the lesson: an American customer's card can depend on a building in England.

U.S. bank rules already cover this kind of failure, and many boards do not realise it. The interagency computer-security incident notification rule, 12 CFR Part 53 for national banks, requires a bank service provider to notify its bank customers "as soon as possible" when it has "experienced a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services provided to such banking organization for four or more hours." A computer-security incident is defined as an occurrence that results in "actual harm to the confidentiality, integrity, or availability of an information system." Availability. No attacker required. The rule's 2021 preamble says the definition "includes incidents from whatever cause." Tuesday's incident ran nearly eight hours on Google's own clock. If a U.S. bank had run covered services in europe-west2-b through a provider that qualifies as its bank service provider, the four-hour line would have been crossed by late morning in London, about 11:08 AM BST. Whether a hyperscaler is a bank service provider for a given bank is a question for that bank's counsel, and it is worth asking before the next outage rather than during it.

The June 2023 interagency guidance on third-party relationships tells boards to expect "Periodic reporting to the board (including, as applicable, dependency on a single provider for multiple activities)" and tells banks to ensure their third parties maintain "business resumption and business continuity plans." The FFIEC's 2020 statement on cloud computing says: "Resilience and recovery capabilities are not necessarily included in cloud service offerings." And the Treasury Department's February 2023 report on cloud adoption put the systemic version in one line: "if an incident occurs at one CSP, it could affect many financial sector clients concurrently."

None of that is new. Tuesday shows what it looks like when it happens.

Medium severity in Mountain View, the whole day in London

Google rated the incident "medium." On the scale of Alphabet, that is fair. Google Cloud reported $24.8 billion in revenue for the second quarter of 2026, up 82 percent, and Alphabet's 10-K for 2025 counts $242.8 billion of remaining performance obligations, "primarily related to Google Cloud." One London zone for part of a morning will not move those numbers. Alphabet's risk factors already say so in advance: "Some of our systems are not fully redundant, and disaster recovery planning cannot account for all eventualities," and "unanticipated problems affecting our data centers could result in lengthy interruptions in our service." The same filing warns that its ability to scale "is increasingly constrained by the availability of power, water, and land."

For Revolut, the same event was most of a business day with card payments, transfers and cash withdrawals impaired across several countries, a parliamentary letter, an FCA statement about ensuring no one is left out of pocket, and, we would expect, a question from its U.S. regulator. That is materiality asymmetry. Immaterial to the provider, material to the client. The provider's disclosures warn of exactly this event in general terms; the client's annual report warns of exactly this event in specific ones. The customer at the till read neither.

What Google and Revolut should have done by now

1. Google: name the power event. Utility loss, switchgear, UPS, generator transfer, PDU, or something else. It has named the physical cause for London in 2022 and 2024, for Paris in 2023 and for Frankfurt in 2024. It can write it for October 20 before the full analysis lands.
2. Google: explain why one zone produced regional symptoms. The fourth update says other zones in the region saw "elevated errors and intermittent network issues." Customers who built for zone failure need to know which regional dependencies failed with zone b, because that is what their architecture did not account for.
3. Google: reconcile the close. State how many customers were still affected when the incident was marked available at 14:03 UTC, and for how long. A designated Critical Third Party should not close the public record without saying so while a financial-sector customer is still reporting most services impaired hours later, even if the residual cause is the customer's.
4. Revolut: publish a post-incident note on the surface customers use. Its status page this morning says "All systems are operational" and carries no history. One paragraph with start time, end time per service, and what customers should check (declined payments, duplicate authorizations, missed direct debits) costs nothing.
5. Revolut: say whether its important business services stayed within impact tolerance. Its board approved its list of important business services. The PRA will ask. Customers and its U.S. regulator should hear the answer too.
6. Revolut: state the architecture change. Multi-zone, multi-region, or a second provider. Its annual report says it is "actively managing concentration risk." Tuesday tested that sentence.

Six things. None requiring new technology. Every one possible this week.

What boards should be asking this week

For any bank, credit union, broker, insurer or fintech, five questions for Monday.

First, which of our important services, and which of our vendors' services, run in a single cloud zone or a single cloud region? Not which provider we use. Which zone. If nobody in the room can answer, that is the finding.

Second, when did we last fail over a critical service to another zone or region for real, in production, and how long did it take? A diagram is not a test.

Third, what is our impact tolerance for card payments, transfers and customer login, in hours, and would Tuesday's event have breached it? Nearly eight hours on the provider's clock, and longer for at least one bank's customers.

Fourth, which of our vendors would owe us notice, as soon as possible, under the U.S. bank service provider rule for an outage like this lasting four hours or more, and do they have our designated contact on file? The rule covers availability incidents from any cause.

Fifth, if our cloud provider closes its incident while we are still down, who tells our customers what happened, and on which page? Revolut's status page has already forgotten Tuesday.

For sponsors and acquirers

Cloud concentration is a diligence item and it is usually reduced to a line in the IT section: "hosted on Google Cloud." That line says nothing. The questions that predict a Tuesday are these. Which regions and zones host revenue-bearing services. Whether any critical path, including identity, payments authorization, databases and message queues, is pinned to one zone. Whether the target has executed a regional failover in the last twelve months and can produce the runbook and the timings. Whether contracts with the provider say anything about notice during incidents, and whether the target's own customer contracts promise uptime its architecture cannot deliver. For fintechs pursuing U.S. charters, add the OCC pre-opening review: business resumption plans are a condition, and regulators now have a public case study.

A week to answer. More predictive than any uptime percentage in a deck.

What we are not saying

We are not saying the outage was a cyberattack. Google attributes it to a power event, and no one has suggested otherwise. We are not saying any customer data was lost or any funds misdirected; Revolut says money and data were safe, and nothing contradicts that. We are not saying Lloyds, Halifax, Bank of Scotland, HSBC or NatWest were affected because of Google; customers reported problems and none of those banks has attributed them. We are not saying Revolut's services ran in a single zone; we are saying Google reports one zone failed and Revolut's services were impaired for most of the day, and only Revolut can explain the gap. We are not saying Revolut's long afternoon was Google's fault rather than Revolut's own recovery; the public record does not separate them. We are not saying any regulator failed; the Treasury Committee has asked what they knew and when, and initial answers are due November 4.

We are saying that the provider, the bank and the regulators all wrote this scenario down before it happened, that the provider's own guidance described the fix, that the same region has had facility failures that spread before, and that when it happened, the public record on every side was thinner than the customers deserved. If Google or Revolut would like to correct any of that, this page will be updated the same hour.

Our record of these incidents

• Google Cloud London (europe-west2) Outage Takes Down Revolut, the verified timeline and running list of unknowns
• BAE Was Hacked and Every Bankruptcy Court Went Silent, on a single contractor failure that cut off every U.S. creditor at once
• Seven Years. Five Wells Fargo Outages. Still 'Routine.', on how banks describe outages, including power problems at data facilities

Sources

• Google Cloud Service Health, Multiple services are experiencing issues in the europe-west2 region (incident Xs2XTHzAVC9YnafnPyzj), October 20, 2026; machine-readable feed retrieved by Cloudskope October 21, 2026, 2:00 AM Central
• Carly Page, The Register, Google Cloud says a power event caused today's outage, October 20, 2026
• Paul Kunert, The Register, Google Cloud's London zones takes a nap, multiple services disrupted, October 20, 2026
• Akanksha Khushi, Reuters, Google Cloud services face outage in London, Revolut services down too, October 20, 2026 (via The Star)
• Ciara O'Brien, The Irish Times, Millions affected by Revolut disruption linked to Google Cloud outage, October 20, 2026
• Kalyeena Makortoff and Julia Kollewe, The Guardian, Millions unable to use Revolut app and cards, October 20, 2026 (via AOL)
• Tom Saunders, The Telegraph, Bank of England investigates Google outage, October 20, 2026 (via AOL)
• Sergiu Gatlan, BleepingComputer, Revolut outage disrupts online banking operations worldwide, October 20, 2026
• Jonathan Benton, Euronews, Digital bank Revolut suffers worldwide outage, October 20, 2026
• TheJournal.ie, Revolut services restored as Google Cloud outage blamed for disruption, October 20, 2026
• Edward Targett, The Stack, Google Cloud incident knocks Revolut offline, October 20, 2026
• Dame Meg Hillier MP, House of Commons Treasury Committee, Letter to the Governor of the Bank of England and the Chief Executive of the FCA: Critical Third Parties regime and Google Cloud service disruptions, October 20, 2026
• Dame Meg Hillier MP, House of Commons Treasury Committee, Letter to the Economic Secretary to the Treasury: Amazon Web Services outage, October 20, 2025
• Bank of England, UK financial regulators to begin overseeing Critical Third Parties announced by HM Treasury, July 10, 2026
• Bank of England, Financial Stability Report, July 2026; Financial Policy Committee Record, September 2026
• Prudential Regulation Authority, PS16/24 Operational resilience: Critical third parties to the UK financial sector, November 12, 2024; SS1/21; SS2/21 (March 2026 update)
• Jeanette Manfra and Tara Brady, Google Cloud, Supporting customers as a critical provider under EU DORA, November 18, 2025
• Revolut Group Holdings Ltd, Annual Report 2025, April 2026
• Revolut, Revolut and Google Cloud deepen strategic partnership to power global growth to 100M customers, September 4, 2025
• Google Cloud, Geography and regions; Google Cloud infrastructure reliability guide: building blocks; Compute Engine: Regions and zones; Financial services perspective: Reliability (updated July 28, 2025)
• Google Cloud Service Health incident reports: europe-west2, July 19, 2022; europe-west9, April 2023; europe-west2, August 12, 2024; europe-west3, October 23, 2024
• Amazon Web Services, Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region, October 2025
• Matthew Sellers, Mortgage Introducer, Lloyds, Halifax, HMRC all hit by massive Amazon problem, October 20, 2025
• Office of the Comptroller of the Currency, Corporate Decision #1390, Revolut Bank US, National Association, September 2, 2026
• American Banker, Revolut wins US charter with limits on four products, September 3, 2026
• 12 CFR Part 53, Computer-Security Incident Notification (eCFR); 86 FR 66424, November 23, 2021
• Board of Governors of the Federal Reserve System, FDIC and OCC, Interagency Guidance on Third-Party Relationships: Risk Management, June 9, 2023
• FFIEC, Security in a Cloud Computing Environment (OCC Bulletin 2020-46), April 30, 2020
• U.S. Department of the Treasury, The Financial Services Sector's Adoption of Cloud Services, February 8, 2023
• Alphabet Inc., Form 10-K for fiscal year 2025; Q2 2026 earnings release, July 22, 2026