When the Cloud Lost Power: How a London Outage Disrupted Revolut

When the Cloud Lost Power: How a London Outage Disrupted Revolut

22 October 2026 | Binary-Tech Institute

Imagine standing at a supermarket checkout. You tap your card. Declined.

You open your banking app to check what happened. That will not load either.

At that moment, you care about one thing: being able to use your money.

On 20 October 2026, a Google Cloud outage in London disrupted Revolut services, including card payments, transfers, cash withdrawals, currency exchange and stock trading. A problem inside the infrastructure behind the app had become a problem in customers’ everyday lives.

It is a reminder of something the word “cloud” makes easy to forget: digital services still depend on physical equipment, reliable electricity and recovery systems that actually work.

Google’s preliminary incident report, published on 22 October, traces the failure to europe-west2-b, one zone in its London cloud region. A grid power interruption put the facility onto batteries. Both the primary and backup automation controllers failed to initiate the generator start-and-transfer sequence. When the batteries ran out, servers, networking equipment and storage lost power.

The effects spread beyond that zone. Redirected workloads overwhelmed spare capacity elsewhere, while some regional services waited for responses from components that were offline. Google’s investigation is continuing, so these findings remain preliminary.

Think of a road closure. Diverting traffic only works well if the alternative roads can cope with the extra vehicles. A diversion sign alone cannot prevent a traffic jam.

That is why the interesting question is what a backup can deliver under pressure.

For customers, the most urgent concern was whether their money was safe. Revolut said customer funds and data remained secure during the disruption.

That reassurance matters. So does access.

Someone trying to pay for groceries, withdraw cash abroad or move money before a deadline experiences an outage through the task they cannot complete. A reassuring statement cannot finish that task for them.

The recovery timeline makes that point particularly clearly.

Google records its main incident window as 07:00–13:10 BST on 20 October, lasting six hours and ten minutes.

Yet Reuters reported that, at 18:00 BST, most services on Revolut’s UK status page were still showing problems. Later that evening, Revolut said the issue had been fixed and services restored, according to Euronews.

There are two experiences of recovery here: the infrastructure provider’s progress and the customer’s ability to complete a payment. For anyone depending on the service, the second is the meaningful measure.

The incident also attracted attention beyond engineering teams. On 20 October, the UK Treasury Committee chair wrote to the Bank of England and the Financial Conduct Authority about the outage and their response. Parliament noted that Google Cloud was among the providers designated under the UK’s Critical Third Parties regime in July.

That scrutiny raises a question every organisation should understand: how much of its ability to serve customers depends on a supplier it cannot directly operate?

Our view at Binary-Tech is that reliability has to be demonstrated through realistic recovery tests.

A diagram showing duplicate systems is a starting point. The useful evidence comes from what happens when a component disappears, traffic rises and people have to recover the service.

Google’s own reliability guidance emphasises understanding dependencies, monitoring failures, planning recovery and testing it. Those principles give businesses a practical way to examine their own systems.

For a business reviewing its arrangements, we would start with four questions:

• What must keep working? Identify the customer actions that matter most, such as paying, signing in or accessing essential records.

• What does each action depend on? Follow the dependencies through the application, database, network and external services.

• What happens when the backup is under pressure? Test recovery with realistic demand and record how long essential tasks take to work again.

• What will customers be told? Explain which functions are affected, what they can still do and when they will receive another update.

These are questions for a review. The public reports do not establish Revolut’s full internal architecture, and they do not justify assuming that it had no redundancy.

For anyone learning technology, this incident also shows why understanding the systems beneath an app is valuable. A polished interface tells you very little about how the service behaves when something breaks.

At Binary-Tech Institute, our free Linux From Zero course introduces the operating system fundamentals. Our Linux Projects course builds practical experience with an Ubuntu server. They are useful starting points for learning how services run, how to investigate problems and how infrastructure fits together.

The promise of digital banking is that your money is available when you need it. Every recovery plan should be judged against that promise.