Revolut outage: UK services disrupted as Google Cloud recovers
The UK status page lists problems with sign-in, payments and transfers. Google reports recovery in its London cloud region, but that is not an all-clear for every banking service.

Verified brief
The story in 60 seconds
Revolut’s UK status page still showed multiple services as partially unavailable when checked at 14:01 UTC on October 20. Google Cloud separately reported recovery for most workloads in its London region. The useful answer is therefore qualified: a provider’s recovery notice does not establish that every Revolut function or individual transaction is working normally.
This brief and the full story below are based on the disclosed sources. SearchTrends Daily’s interpretation appears later under “Our take.”
Full reporting
The complete story
Is Revolut down, or has the problem been fixed?
At our 14:01 UTC check on October 20, Revolut’s official United Kingdom page carried a partially unavailable status and incident notices for functions including sign-in, card payments, transfers, ATM withdrawals and live support chat. The page marked those notices as detected at 07:47 UTC. This was a reading of the company’s status page, not a test using a customer account. It does not establish that every user or attempt failed.
Google Cloud’s separate incident record identifies London, europe-west2, as the affected region. Google attributes the disruption to a power event in the europe-west2-b zone and says the power event has been mitigated. Its detailed bulletin describes recovery, rather than an unconditional end to every downstream problem.
AP reports disruptions at Lloyds, Halifax, HSBC and Revolut; Lloyds said its app was operating again. That is an attributed report about one bank, not evidence that Revolut’s functions had recovered. Our central availability check comes from Revolut’s own UK page.
The timeline, with times converted to UTC
06:08 on October 20: the start of the cloud incident recorded by Google. Its dashboard displays the equivalent as 23:08 US/Pacific on October 19.
07:47: the detection time attached to the UK service notices observed on Revolut’s page.
12:10: the point from which Google says most workloads were recovering, according to its 12:44 UTC bulletin.
14:01: our direct check still found Revolut’s UK disruption notices.
Those times answer different questions. The provider’s start time and an application’s detection label are not interchangeable, and neither tells us when a particular customer first encountered a problem. Subtracting them would not produce a reliable measure of delayed notification.
What the current record does not establish
The reviewed pages do not provide a count of affected Revolut customers or a transaction-by-transaction outcome. Nor does this report establish one worldwide service state: its direct application-status observation is the UK page. Search interest elsewhere is a reason to investigate, not proof that the same functions failed in every country. No customer’s balance, payment or account has been inspected.
Source perspectives
What other reporting adds
These are the reports, official records, and trend observations used to build the story. The note under each link explains exactly what it contributes.
Direct UK service-page observation at 14:01 UTC on October 20. Availability notices are not an account-level audit or a count of affected customers.
Read original source ↗Google CloudLondon region incident: official detailed timelineProvider’s cause, affected zone and recovery bulletins. Dashboard uses US/Pacific; times in this report are converted to UTC. Recovery estimates are not completion receipts.
Read original source ↗Google CloudEuropean regional service-health dashboardRegional scope and active incident listing. Does not establish the status of every downstream application.
Read original source ↗Associated PressGoogle Cloud outage hits UK banksIndependent banking-impact context, read in full; updated October 20 at 13:40 UTC. No licensed photographs or quotations reused.
Read original source ↗SearchTrends Daily opinion
Our take
Analysis
What the evidence and search signal suggest
Our analysis: there are three separate recovery questions
First, has the infrastructure provider restored the affected workloads? Second, has the application operator confirmed that each affected function is available? Third, what happened to an individual operation submitted during the disruption? The evidence needed to answer one question is not a substitute for the evidence needed for the next. This is a framework for reading the notices, not a claim to know Revolut’s internal architecture.
That distinction also limits what a screenshot or social post can demonstrate. A successful action can be genuine without representing everyone’s experience; a failed attempt can be genuine without proving total failure. Neither should be promoted into a customer count. Search trends reveal questions people are asking, not the population affected by the technical fault.
The strongest next assessment will compare time-stamped notices with their stated scope. If the cloud record closes while the application still lists interruptions, both facts can belong in the same report. If the application posts an all-clear, we should revise the availability language while retaining the history of what readers were told earlier. A delayed or incomplete status notice is a possibility to check, not something this evidence alone proves.
Analysis and commentary are SearchTrends Daily’s interpretation. They are intentionally separated from the sourced account above.
Meaning
Why this matters
For readers trying to understand an outage, the difference between infrastructure progress and an application all-clear is practical, not semantic. One statement concerns the systems a provider operates; another concerns the service a customer is trying to use. Combining them into a single recovered/not-recovered headline would discard information that is still important. The status of a specific payment cannot be deduced from either a broad outage report or an unrelated successful login.
Background
How we got here
This is a developing October 20 incident, not an old outage being recirculated as new. The public record has moved through investigation, mitigation and recovery language during the day. Earlier estimates should be read as estimates made at that stage, not as proof that restoration occurred on schedule. A final incident review would serve a different purpose: explaining the sequence, causes and safeguards after the immediate service-status question has settled.
Outlook
What is likely to happen next
The next material trigger is an explicit change on Revolut’s UK status page, a new Google Cloud bulletin or a final incident report. We will revise the current-state passages if those records confirm restoration or a change in scope, and preserve the earlier observation in a dated update.
A final cloud closure would change our description of the provider incident; it would not, by itself, settle every application or individual transaction question. Likewise, one bank’s recovery should not be generalised to others. This article reports public service notices and their limits; it does not offer personal banking, investment or account-recovery advice.
A conditional editorial assessment based on the evidence available at the review date, not a guaranteed outcome.
Live record
Updates to this story
No material updates yet.
Commentary
What we think
SearchTrends Daily opinion: an outage report should make uncertainty easier to navigate, not replace it with confident shorthand. We would rather give a dated, scoped answer than imply that a power issue being mitigated guarantees every service is back. Operators’ next useful contribution is a clear account of which functions are restored, which remain affected and what evidence supports the all-clear.