When the cloud goes down, can your customers still pay?

The Telegraph’s report of 31 October describes a ten-hour Revolut outage following a power issue at a Google Cloud data centre in London. According to the report, disruption reached account access, transfers, card payments and cash withdrawals. For customers, these are not separate technical functions. Together, they determine whether money is usable when it is needed.

The lesson is not that cloud banking is inherently unsafe, or that older systems are resilient by default. It is that a supplier’s infrastructure incident can become your customer’s financial emergency. The outage alone does not establish a regulatory breach, and public reporting cannot reveal every architectural decision behind it. But it gives boards a useful scenario to test against their own arrangements.

Count independent recovery paths, not supplier names. Two providers do not necessarily give you two working options. A backup environment may still depend on the same identity service, network connection or deployment tooling as the primary one. Trace those dependencies through a complete payment journey. Ask what can still operate if the component needed to activate recovery is itself unavailable.

A recovery timer should end with a usable service. Restarting infrastructure is only one milestone. Teams must establish whether customers can authenticate and complete transactions, whether balances are accurate, and whether pending requests can be reconciled without duplication. A test that stops when servers are healthy can miss the longest, most consequential part of recovery.

For EU financial entities within scope, DORA Article 11 requires ICT business-continuity arrangements, response and recovery plans, and testing. This is not a blanket rule for all UK firms. The practical challenge is to make recovery objectives reflect business impact: how long can a payment service be unavailable before customers face unacceptable consequences, and can the tested recovery process meet that objective?

Customer communication needs its own fallback. If the app is unavailable, an in-app notice is not enough. Test a status channel that does not share the same failure point. Say which services are affected, what customers should do about pending payments and when the next update will arrive. Avoid suggesting repeated retries before their transaction consequences are understood.

At the next board meeting, replace ‘we have a backup’ with three questions. What shared dependency could disable it? When did we last demonstrate a completed customer transaction after failover? Who checks balances and pending payments before normal service resumes? The evidence that matters is a recovered customer journey, not a reassuring architecture diagram.