Google’s London cloud outage disrupts banking as services recover

Revolut customers faced disruption to card payments and cash withdrawals on Tuesday, October 20, while Google dealt with a power incident in its London cloud infrastructure. Reuters reported the banking problems and, citing a person familiar with the matter, linked Revolut’s outage to Google Cloud. Revolut said customers’ money and data were safe, according to the report.

Google’s 12:58 p.m. British Summer Time update said the power problem had been contained and services were recovering. It was giving priority to existing applications and computing jobs; customers might still be unable to start new ones. The company tentatively expected existing work to recover by 2 p.m. BST. That remained a forecast, rather than confirmation of completed restoration.

The incident began at 7:08 a.m. BST, or 6:08 a.m. UTC, on Tuesday, according to Google’s public incident feed. The Monday start date on its dashboard reflects Pacific time.

The distinction in Google’s update matters to anyone waiting to pay: containing a power problem, recovering cloud services and restoring a particular banking function are three separate milestones.

Google identified the power incident in europe-west2-b, one zone within its London region, europe-west2. A region groups together several zones; a zone is a deployment area intended to provide a boundary around failures. Google’s geography documentation distinguishes services running within one zone from those distributed across zones or regions.

That distinction does not turn a zone’s name into a complete map of the disruption. Google still warned that services were unavailable in the affected zone and that some services in the London region could experience errors and intermittent network problems. Its notice did not describe all European infrastructure as unavailable.

A banking service also needs more than a running computer. Google’s reliability guide explains how applications depend on layers of infrastructure: software handling a request may need a database and working connections between components. If an essential layer is unavailable, the application can become unavailable too.

Distributing copies across zones can improve resilience to local failures. But that general design principle does not reveal which safeguards any affected bank used, or precisely which dependency interrupted a particular transaction. The published notices do not document those banks’ architectures.

The payment provider Volume offers a concrete example of recovery happening in stages. At 8:57 a.m. BST, it announced a fix and said it was monitoring results. At 9:15 a.m., it reported continuing payment failures, which it attributed to Google Cloud’s outage. Its 10:20 a.m. update again reported a deployed fix while describing continuing problems involving Lloyds Group and Revolut. A fix announcement had not amounted to an all-clear for every payment route.

Around 1 p.m. BST on Tuesday, UK notices described different combinations of working and disrupted functions:

Tink’s notice concerns open-banking connections used to retrieve account information or initiate payments. Its scope differs from Reuters’ report about Revolut cards and cash withdrawals. Likewise, Volume’s notice describes its payment routes, rather than every service offered by the banks it names.

HSBC’s notice did not attribute its branch and telephone difficulties to Google. Its normal-service listings establish the bank’s stated position at that point; the undated page does not establish when those functions recovered or whether they had experienced earlier disruption.