Revolut’s Outage Exposes the Cost of single Cloud Dependence

For a bank that wants to become central to everyday financial life, availability is a fundamental obligation. Customers must be able to pay, withdraw cash and access their accounts even when an infrastructure supplier encounters serious problems.

On 20 October 2026, Revolut failed that test. An outage linked to Google Cloud disrupted account access, card payments, transfers, ATM withdrawals, currency exchange and stock trading. Revolut subsequently confirmed that services had been restored and that customer funds and data remained safe throughout. Nevertheless, safe funds offer limited reassurance when customers cannot use them.

The disruption reached across Europe, with reports from countries including the UK, Ireland, France, Spain and Romania. Its impact also extended into parts of Asia, including Singapore, where Revolut’s status page flagged service disruption. A failure originating in London had consequences far beyond the UK.

The scale of Revolut’s responsibility matters. The company had already reported more than 40 million customers in Europe in May 2025. That figure describes its European customer base at that time, rather than the number affected by this outage, but it establishes how many people potentially depend on the resilience of its infrastructure.

Google reported a power-related failure in its London cloud zone, europe-west2-b, with additional errors and intermittent network problems across the surrounding London region. Its official incident window was 08:08–16:00 Central European time.

Infrastructure failures are foreseeable. A financial institution’s architecture should assume that they will happen.

Revolut publicly expanded its strategic partnership with Google Cloud in September 2025, presenting Google’s infrastructure as a foundation for global growth. The full details of Revolut’s failover arrangements have not been disclosed in the material reviewed, so this incident alone does not prove that every system runs on one provider. It does, however, expose the consequences of a critical dependency that its continuity arrangements failed to contain.

A bank of Revolut’s importance should not allow access to essential services to depend on one cloud provider’s recovery. Outsourcing infrastructure does not outsource responsibility to customers.

For critical banking functions, multicloud redundancy should be a vital part of the resilience strategy. Independent providers can offer alternative operating environments when a primary provider suffers a serious failure. Google’s own architecture guidance recognises hybrid and multicloud patterns for business continuity.

But signing a second cloud contract is only the beginning. Effective redundancy requires functioning applications, safely replicated transaction data, sufficient standby capacity and regularly tested failover. Authentication, networking and other shared dependencies must also survive the loss of the primary environment. A secondary deployment is useful only if customers can actually complete transactions through it.

This makes the management of dynamic network data equally important. Resilience depends on how current information about reachability, network performance, service response times and server load informs routing decisions. Where applications and data are stored is only one part of the problem; directing each customer to a functioning service is another.

That is where DynConD can contribute to the solution. We support multicloud and hybrid environments by using measured network distance, service response time and server load to select among available servers. Combined with replicated applications and a tested recovery architecture, DynConD can help turn infrastructure redundancy into usable service continuity. For essential financial services, intelligent management of dynamic network data belongs alongside resilient data storage at the heart of the design.