Why was every Revolut card declined on 20 October 2026? The outage explained

If your Revolut card was refused this morning, at a till, a fuel pump or a cash machine, the card was not the problem and neither were you. On the morning of Tuesday 20 October 2026, Revolut suffered a company-wide outage. Card payments, transfers, ATM withdrawals and even signing in to the app failed for customers in the UK, France, Spain, Germany and Greece, as well as in Ireland. Revolut confirmed a service disruption affecting multiple services and said that all customers’ money and data are safe. The most likely trigger is a Google Cloud failure in its London region that began at 06:08 UTC, which is 08:08 in Paris, and which Google has since attributed to a power event. A person familiar with the matter told Reuters that Revolut’s outage was related to the Google Cloud disruption. Neither company has confirmed that link publicly.

The live coverage tells you that Revolut is down. It does not tell you where in the payment chain the failure sits, why an unattended fuel pump refuses your card even when a till sometimes accepts it, or how one cloud region in London can stop a card in a French petrol station. This post answers those questions, separates the outage from the recent strikes on Russian data centres and from a newly disclosed Linux virtual-machine flaw, and lists what to carry so that a single issuer outage never strands you again.

Why was my Revolut card declined on 20 October?

Because Revolut, the company that approves every payment made with its cards, could not answer for several hours. From around 08:00 Paris time, Clubic reports, the app showed an error message, cards were refused in shops and taxis, and transfers failed. Revolut has more than 8 million customers in France alone. French tech press reported declines at tills and at ATMs.

Revolut's own status page was slow to catch up. At 09:42 Paris time it still showed all systems operational; it later listed 31 services as partially unavailable, including card payments, transfers, ATM withdrawals, premium services and signing in. Here is the morning as it unfolded.

As of 13:25 Paris time on 20 October, Google attributes the outage to a power event in the europe-west2-b zone, says the power event is mitigated and that services are being restored progressively, but its incident remains open and its full incident report has not been published. Revolut has issued no recovery notice and has not named a cause. We will update this post when Revolut or Google publish a post-mortem.

Was it Revolut, Visa or the shop?

Every card payment involves three parties. The shop's terminal and its bank (the acquirer) capture the card and send an authorisation request. The card network, Visa, Mastercard or CB in France, routes that request. The issuer, the bank behind your card, answers yes or no in real time. On 20 October, we found no incident reported by Visa, Mastercard or CB, and no other card issuer reported card problems, which by all evidence places the failure with Revolut as the card issuer.

An issuer outage is when the bank behind your card cannot answer the payment network's approval request, so every terminal declines the card at once, whatever the shop and whatever the country. That is why the pattern looked so strange from the outside: the card failed everywhere simultaneously, while the person next to you paid without trouble.

It also explains why unattended fuel pumps refused every time while a till sometimes accepted a card. A French 24/7 automated pump asks the issuer to approve a fixed maximum amount before you lift the nozzle, often 100 to 150 euros set by the station, then replaces it with the real amount afterwards. That pre-authorisation needs a live answer from the issuer, so when the issuer is silent, the pump says no every time. The pump makes an issuer outage visible; it does not cause it. One possible explanation for the payments that did go through is that some terminals can approve small amounts offline and settle them later, which may be why Clubic reported that some Revolut customers could still pay in some shops while most cards were refused.

What does Google Cloud have to do with my bank card?

Many banks and fintechs run much of their software on rented cloud infrastructure, and when that infrastructure fails, their services can fail with it. Google says the problem began at 06:08 UTC; its first status update, posted at 10:35 Paris time, about two and a half hours later, reported elevated errors and intermittent network failures in europe-west2, its London region. For a cardholder that gap mattered. For about two and a half hours Google's status page said nothing, and at 09:42 Paris time Revolut's still showed all systems operational. The Register notes that europe-west2-b is one of three availability zones in that region. Google's incident page lists 38 impacted products, including Kubernetes Engine, Cloud Run and BigQuery Data Transfer Service, and Google posted an apology to all who are affected. At 13:12 Paris time, Google named a first cause: "Due to a power event we had suffered an outage within europe-west2-b zone. The power event is mitigated," its update reads, with services being restored progressively. Google's statement concerns its own zone and does not mention Revolut. Other Google regions in Europe, including Paris and Frankfurt, reported no problems.

The connection to Revolut remains attributed, not confirmed. A person familiar with the matter told Reuters that Revolut's outage was related to the Google Cloud disruption, and Revolut's own statements do not mention Google. The Journal reported that the disruption is understood to stem from an outage at a third-party provider, without naming one. The same morning, Downdetector UK showed spikes for Lloyds, Halifax, Bank of Scotland, HSBC, NatWest, Santander UK and MBNA, plus Royal Mail, Rightmove and GOV.UK, and ING Germany customers had problems logging in to online banking and the app. Nobody has officially tied those reports to Google Cloud, and Downdetector spikes can mislead, since worried users check services that are actually fine.

Whatever the final post-mortem says, the shape of the event is familiar. In September, when ChatGPT, Claude and Grok failed together, a shared cloud was the first suspect and turned out not to be the cause; this time, a single cloud region is the leading explanation, though still unconfirmed. When many companies rent the same building, one fault in that building can become everyone's fault at once, and this time the service in question was the card in your pocket.

Was it a cyberattack, or linked to the strikes on Russian data centres?

No, on the evidence available. Since 8 October 2026, Ukrainian drones have hit Yandex data centres in Sasovo, Kaluga and Vladimir, disrupting Yandex services in Russia and neighbouring countries; we covered those strikes in detail here. Coverage of those strikes mentions no effect on European banks, card payments or Western cloud providers. Revolut does not operate in Russia. The Revolut outage coincided with a Google facility problem in London, and no source connects the two events. They rhyme in one way only: both show that critical services sit in a small number of physical buildings. But one is a military strike on infrastructure and the other is an ordinary cloud failure, and confusing them helps nobody.

Nor does anything point to a hack. No source reports an intrusion, Revolut says customers' money and data are safe, and the budgeting app Emma, also affected this morning, described its own problem as a technical failure and not a security breach. A cyberattack is not formally excluded until a post-mortem appears, but everything visible today points to a cloud incident, not an attack, and Google itself now attributes its London outage to a power event in the europe-west2-b zone, with its full incident report still to come.

Was it the PwnEscape Linux flaw, or part of a run of cloud outages?

A second question deserves the same treatment. Could a newly disclosed Linux flaw be behind it? On 15 October 2026, five days before the outage, the Linux kernel's CVE team published CVE-2026-99999, nicknamed PwnEscape, a critical flaw in the kernel's networking code, in its IPv4 checksum handling, rated 9.3 out of 10 under CVSS 3.1. The rating is high because of what the bug allows. A malicious guest virtual machine can send crafted network packets that corrupt the kernel of the host machine it runs on, and the researchers demonstrated host memory leaks, host crashes and running code as root on the host, in their own lab. The flaw sits in the Linux networking stack that handles guest traffic, not in one specific hypervisor.

The discovery itself was orderly. The research team PWN.AI found the bug during Vercel's sandbox security challenge, reported it privately to kernel maintainers on 4 September, and the fix landed in the main Linux kernel on 14 October. More to the point, no exploitation in the wild has been reported. CISA's assessment of 16 October, recorded on the CVE entry, states "Exploitation: none", and the flaw is not in CISA's catalogue of known exploited vulnerabilities. Google has published no security bulletin about it, and its bulletins up to 19 October do not mention it. Google attributes the London outage to a power event in the europe-west2-b zone, Revolut's statements mention neither Google nor any vulnerability, and Emma described its own problem as a technical failure and not a security breach. No credible source links PwnEscape to this outage.

The backdrop is real, though. This autumn brought a run of large cloud incidents. On 1 September, network fibre cables disconnected during routine router maintenance isolated parts of two zones in Google Cloud's us-central1 region in Iowa for about four hours, from 07:41 to 11:52 US Pacific, affecting 16 products. From 30 September to 1 October, Microsoft Azure gateway services, including ExpressRoute, VPN Gateway, Azure Firewall, Application Gateway and Azure VMware Solution, were disrupted in 18 regions from 20:30 UTC, and Microsoft cited a correlation with infrastructure operating system servicing activity. On 8 and 9 October, a load-balancing configuration update overloaded Google Cloud Storage nodes in us-central1, causing write errors for a total of about 18 hours over two days.

The fair takeaway follows from those reports. The run of incidents is real, and it shows how much depends on a handful of providers, but the stated causes were maintenance work, configuration changes and capacity, and none of those reports mentions an attack or a vulnerability. The London outage now fits that pattern: Google attributes it to a power event, another non-attack cause, though its full incident report is still pending.

Why do phishing messages follow outages?

Because an outage hands scammers a ready-made story. Thousands of people just had a card declined, are worried, and are waiting for a message from their bank. A fake SMS saying your card has been suspended, with a link to verify your details, is far more believable on a day like today than on a normal Tuesday. Expect a wave of them in the coming days, by SMS, email and phone call.

There is a reason to take this seriously with Revolut in particular. In September 2026, an attacker posing as an Italian government regulator, emailing from a legitimate government domain, obtained data on about 650 customers, including ID documents, photos, account statements and transaction histories. Revolut called it a sophisticated external impersonation scam, said its systems and customer funds were not affected, and contacted those affected. That leak is not linked to the 20 October outage, but it means some customers' real details are in circulation, which makes a phishing message look convincingly personal.

No genuine bank support agent needs your PIN, passwords, one-time passcodes or card details, and none will ask you to approve something in your app because they called you; if in doubt, hang up and contact the bank through its app. Do not tap links in messages about the outage; open the app directly and read its notices. As a backstop, Le VPN's Threat Protection blocks known phishing and malware domains before they load. It cannot stop an SMS from arriving or catch every brand-new scam domain, so your own scepticism remains the first line of defence.

How do you avoid being stuck next time?

You cannot prevent the next Revolut outage, but you can make it a non-event for yourself.

• Carry a second card from a different issuer. A second Revolut card fails together with the first. For residents of France, a French bank card on the CB network is a good complement, since a different issuer approves it.
• Keep some cash. Enough for fuel and food. Revolut ATM withdrawals were down too, so the time to withdraw it is before an outage, not during one.
• At the petrol station, a staffed kiosk is worth trying rather than the automated pump during an issuer outage, though it may decline too.
• Check the status page and in-app notices first. Before assuming your card is blocked or compromised, see whether the issuer is reporting an incident. Revolut also lists ordinary decline reasons, such as a frozen card, a spending limit, a pending 3-D Secure confirmation or a disabled payment type, with the specific reason shown in the app.
• Do not freeze, cancel or reset the card in a panic. During an issuer outage that changes nothing, and a cancelled card means waiting for a replacement once service returns.
• Never give details to anyone who contacts you claiming to be Revolut support, today of all days.
• Keep timestamped screenshots of declined payments and failed transfers if they cost you money, and raise it with Revolut support through the app once service is restored.

One thing that would not have helped is a VPN, and we say that as a VPN provider. Card authorisation runs between the terminal, the card network and the issuer; your own connection, with or without a French VPN server, plays no part in whether a payment is approved. A VPN protects your traffic and, with Threat Protection, filters out many of the scam domains that follow a day like this. It does not keep a bank running.

Google has given a first cause, a power event in its europe-west2-b zone, but the full incident report is still to come. When it arrives, three things are worth watching: exactly what the power event knocked out, whether Revolut confirms the Google Cloud link in its own words, and why its status page showed all systems operational while cards were already being declined at tills across Europe.