At 06:08 UTC on Tuesday 20 October 2026, Google Cloud's europe-west2 region — its London region — began throwing errors. Within two hours, millions of people across the UK and Ireland discovered they could not pay for things.
Revolut was the most visible casualty. Card payments, ATM withdrawals, transfers and account logins all failed or degraded. The company confirmed a service disruption affecting multiple services and stated that "all our customers' money and data are safe."
But Revolut was not alone, and this is where your framing needs widening. Reporting also places Lloyds, HSBC, Halifax, Royal Mail, DPD, NHS England and ING Germany among those affected. One cloud region in London, and a chunk of British daily life stopped functioning.
Three clarifications up front:
There is no evidence of an attack. Nobody has suggested one. This is an infrastructure failure, and treating it as a security incident would be wrong.
Customer money and data are not at risk. Both Revolut and Google have been consistent on this point.
This is a developing story. At the time of writing, there was no confirmed restoration time, and Google had not published a root-cause analysis.
What happened
The Google Cloud incident
Google's status page recorded the incident as beginning Monday 19 October at 23:08 PDT — 06:08 UTC on Tuesday. The description was characteristically terse: "Multiple Google Cloud services are experiencing elevated errors and intermittent network failures in europe-west2 region."
Services reported as affected included BigQuery, App Engine, Looker, Cloud SQL, Cloud Filestore and Google Kubernetes Engine. In other words, databases, container orchestration, storage and analytics. The foundations rather than the furniture.
Google advised affected customers to move workloads to other regions, continued to say its engineering team was investigating, and apologised. The Register reported there was no estimated recovery time and no workarounds available.
On the cause: administrators discussing the incident publicly attributed it to a power failure at the London data centre, with power restored and networking being brought back up. Google had not officially confirmed this at the time of writing, so treat it as a credible report rather than fact. Google's own post-incident reports for comparable europe-west failures in 2020 and 2024 both traced back to power events, so the pattern is plausible.
The detail that matters most
Several reports, including The Register's, indicate the failure centred on europe-west2-b — one of the three availability zones in the London region.
Availability zones exist precisely so that this cannot happen. They are physically separated failure domains, and the entire architectural promise is that losing one should be survivable. An outage confined to a single zone should be an inconvenience for well-architected systems, not a national payments event.
That it was not raises an uncomfortable question for every organisation on the affected list: were these systems actually multi-zone, or only nominally so?
What Revolut said and did
Revolut's status page showed most services unavailable or partially unavailable, including card payments and ATM withdrawals. The company's public statement acknowledged the disruption, confirmed money and data were safe, said it had been working on the issue since it was identified that morning, and apologised. It committed to a customer update at around 09:30 UTC.
A person familiar with the matter told Reuters that Revolut's outage was related to the Google Cloud disruption.
Why Revolut specifically
Revolut's dependence on Google Cloud is neither a secret nor new. When Google launched the London region in 2017, Revolut's co-founder and CTO Vladyslav Yatsenko was quoted in Google's own launch announcement, describing Google Cloud as letting Revolut stay agile while providing secure, reliable services at scale.
That is a long-standing architectural choice, made for good reasons — and on a normal day it is an advantage. For a cloud-native bank with no legacy data centre, the cloud is the bank.
One caveat on your brief: it describes Revolut as running its entire backend, mobile app and anti-fraud tooling on Google infrastructure. Revolut is clearly a major Google Cloud customer and the outage clearly reached core payment services, but neither Revolut nor Google has published an architecture breakdown. I would say "core systems" rather than "everything."
Similarly, I could not verify the figure of 36 affected Google services. Google's status page says "multiple services" and names a set that includes those listed above. If you want a number in the piece, I would attribute it carefully or leave it out.
Why it matters
Concentration risk stopped being theoretical this morning. A single region — arguably a single zone — within a single provider simultaneously degraded retail banking, a postal service, a parcel carrier and parts of the NHS. No attacker achieved that. A power distribution unit may have.
Cloud-native banks have a different failure profile. A traditional bank with its own data centres fails slowly and in parts. A cloud-native bank fails cleanly and completely, then recovers cleanly and completely. Neither model is superior in the abstract, but the second concentrates the risk into a dependency the bank does not operate and cannot fix.
Availability zones are a promise, not a guarantee you have claimed. Paying for a multi-zone region does not make your application multi-zone. If your database has a primary in one zone and your failover has never been tested, you have single-zone architecture with a multi-zone invoice.
Payments are critical national infrastructure now. When people cannot buy lunch, the distinction between "financial services outage" and "public incident" disappears. UK and EU regulators have been building frameworks for exactly this — the EU's DORA regime covers ICT third-party risk for financial entities, and the UK has its critical third parties regime for providers like the major clouds. Today is the scenario those rules were written for.
And a note on context. Revolut had a difficult September, with two separate data incidents reported, including one at a third-party provider. Those were security matters. Today is not. Conflating them would be lazy, but the cumulative reputational effect on customers is real regardless of the category.
Who is affected
Revolut customers across the UK, Ireland and Europe — with roughly 3.4 million customers in Ireland alone — unable to pay by card, withdraw cash, transfer money or log in.
Customers of other affected banks, including Lloyds, HSBC, Halifax and ING Germany.
Royal Mail and DPD, with delivery and tracking operations disrupted.
NHS England services reported as impacted — a reminder that healthcare runs on the same commodity infrastructure as everything else.
Anyone hosting in europe-west2, including businesses with no public profile who are simply offline today.
Merchants, who lost sales from customers whose only payment method was a Revolut card.
What organisations should do
Today, if you are affected
Check whether your workloads can fail over to another region, and whether anyone has the authority to trigger it. Google's advice was to move workloads elsewhere — which only helps organisations that built for it.
Communicate early, specifically and repeatedly. Revolut's messaging was prompt and clear on the essential point: money is safe. Customers tolerate outages far better than silence.
Warn customers about phishing now. Outages are reliably followed by "verify your account" and "claim compensation" scams exploiting the disruption. Say which channels you will use.
Keep a manual fallback for critical customer journeys, even a degraded one.
Architecture
Verify your zone redundancy rather than assuming it. Confirm that databases, caches, queues and control planes all have live replicas in other zones — and that failover has been tested under load, not just in theory.
Test failover regularly and deliberately. One administrator in today's discussions reported a database that failed to start after failover. That is what untested failover looks like.
Treat regional failure as a design requirement, not an edge case. For systemically important services, multi-region — and for some, multi-provider — is the honest answer, with the cost and complexity that entails.
Map your single points of failure, including the ones you do not own. Most organisations cannot currently answer "which of our critical services share one cloud region?"
Governance and regulation
Document your ICT third-party dependencies. Under DORA, EU financial entities must maintain a register of information on ICT third-party arrangements and have exit and continuity strategies for critical providers. This incident is a live test of whether yours reflects reality.
Ask your providers hard questions about zone isolation. If a single-zone power event can degrade a region, that should inform your architecture decisions.
Rehearse the regulatory clock. Operational incidents of this severity carry notification obligations. Know who files, to whom, and within how long, before you need to.
For customers right now
Carry an alternative payment method. Today's lesson for individuals is not to rely on one card or one app.
Do not repeat failed payments without checking as duplicate charges are common once systems recover.
Ignore unexpected messages about the outage, especially any asking you to verify details or claim compensation.
Final thoughts
There is no villain here. Nobody was hacked, nothing was stolen, and the engineers at both companies are having a considerably worse day than anyone reading about it. What happened is more mundane and more instructive: a failure domain that was supposed to be contained was not, and the consequences propagated outward through every organisation that had quietly assumed it would be.
The lesson: resilience is not something you buy from a cloud provider, it is something you architect on top of one. Google sells three availability zones in London. Whether your bank, your hospital or your parcel network actually used all three is a decision made internally, years earlier, usually under cost pressure and rarely tested.
The second lesson is about visibility. Most organisations on today's list probably couldn't have told you yesterday that they shared a single point of failure with a postal service and the NHS. Dependency mapping is tedious, unglamorous work that produces no feature anyone can demo — and it is the only way to know what happens to you when a data centre in London loses power.
Two questions for this week, once the dashboards go green again: has your failover to another zone ever actually been executed under load — and do you know which of your critical suppliers are sitting in the same region you are?
