What the Revolut outage shows about your business's core dependencies

At about seven o'clock this morning, Revolut customers in Ireland found that the app would not open and their cards would not pay. By mid-morning, some Irish supermarkets were making announcements that shoppers might not be able to pay with Revolut. Revolut told RTÉ that a power outage at a Google Cloud data centre in London had caused serious network disruption to its services.

For Revolut's 3.4 million or so customers in Ireland, it was an awkward morning. For any business that takes payments, pays staff or runs company cards through Revolut, it was something more serious: several hours in which a core system stopped working for reasons that had nothing to do with them, and that they had no way of fixing.

This post is about that second group, and about every organisation that depends on systems it does not run. That is nearly all of them.

What happened on 20 October 2026

Google's service health page reported that multiple services in its London region, europe-west2, began failing at 06:08 UTC, which was 07:08 Irish time. Google later attributed the failure to a power event in one zone of that region. Revolut's own status page, which customers said showed everything as operational in the early stages, went on to list 31 services as partially unavailable, including card payments, transfers, ATM withdrawals and signing in, as TheJournal.ie reported. Revolut confirmed that customers' money and data were safe.

Google reported that most workloads were recovering shortly after 1pm Irish time, and its status page records the incident as lasting just under eight hours. Revolut was not the only company affected. Customers of banks and other businesses in the UK and across Europe reported problems in the same window.

Put plainly, a power problem in one part of one data centre in London meant that people in Ireland could not pay for their shopping.

The dependency behind the dependency

Most business owners could name their bank and their card provider without thinking. Far fewer could name what their bank runs on, and I doubt many had "a Google data centre in London" on their list of things that could stop them taking payment on a Tuesday morning.

That is the nature of external dependencies. You know the systems you chose. You rarely know the systems they chose. A small business might use one provider for card payments, another for banking, a third for bookings and a fourth for email, and believe it has spread its risk. If three of those four are hosted on the same cloud platform, then for the purposes of an outage they are one supplier.

This is concentration risk: the exposure created when many services, or many organisations, rely on the same underlying provider. A small number of cloud platforms now host a very large share of the services businesses use every day, so a single failure can reach organisations that have never signed a contract with that platform.

None of this is new, and Revolut has been here before. In July 2017, a failure at its then card processor took down card payments for Revolut and several other UK fintechs for a morning, and Revolut advised customers to carry a spare card. The supplier was different. The lesson remains the same.

When a football match lost its digital tickets

The same thing has happened to live events. On 19 July 2024, a faulty software update from the security firm CrowdStrike crashed Windows computers around the world, and Microsoft later estimated that 8.5 million devices were affected. That evening, Essendon were due to play Adelaide in the AFL at Docklands Stadium in Melbourne, and ticketing at the ground was hit.

Both clubs told supporters that membership cards and tickets saved in the club apps were not working. Fans were asked to bring printed tickets, PDFs saved to their phones or tickets stored in their phone wallet, and members whose digital cards failed were sent to specific gates for help. The gates opened late, and the match went ahead.

Three things in that story apply well beyond sport. First, nobody at the ground had made a mistake, and nobody at the ground could fix it. The failure sat several steps along the chain, in a security product most supporters had never heard of. Second, some routes in still worked. Paper tickets, physical membership cards and downloaded PDFs scanned; tickets that depended on the app did not. Knowing which of your systems can keep working without the failed part, and which cannot, decides what you do in the first hour. Third, timing. The update went out in the Australian afternoon, a few hours before the gates were due to open, so the response had to be organised in hours. The same failure three days earlier would have been a technical recovery job. On match day, it was an operational problem at the turnstiles.

A shop on a Tuesday morning is a long way from a football ground on a Friday night, but the questions are the same ones.

Plan for the loss, not the cause

A continuity plan that tries to list every cause of an outage (a power cut, a cyber attack, a faulty update, a supplier going out of business) will never be finished, and it will miss the one that happens. Nobody's plan this morning had "power event in europe-west2-b" written in it.

A better plan is written the other way round. It assumes the system is unavailable, for whatever reason, and sets out what you do next. Nobody in Melbourne needed to understand a faulty CrowdStrike update to open a gate for supporters holding paper tickets. For a small business, the same approach makes the exercise manageable. You do not need to know why your payment provider is down. You need to know what you will do when it is.

How to map your external dependencies

This is an afternoon's work for most small businesses, and a structured exercise across departments for larger ones. The steps are the same.

1. List the services you could not work without for a day. Start with money coming in (card terminal, payment links, online checkout), money going out (business banking, payroll, supplier payments), communications (email, phones, messaging) and whatever system stores your customers, orders or bookings.
2. For each service, write down who runs it and, where you can find out, what it runs on. Providers often name their hosting platform on their security or trust pages, or will tell you if you ask. You are looking for overlap: services that share a provider will fail together.
3. Decide how long you can manage without each one. A few hours without accounting software is an irritation. A few hours without card payments on a Saturday is lost trade. ISO 22301 calls this the maximum tolerable period of disruption. In plain terms, it is the point at which an outage goes from annoying to serious.
4. Name a fallback for each, and check that it works. That might be a second way to take payment from a different provider, a second business bank account with enough in it to cover a week of essentials, offline mode switched on and tested on your till, or a printed list of the day's bookings. A fallback that has never been tried is a guess.
5. Work out how you will know something has failed. Several Revolut customers said this morning that the status page showed everything as operational while services were failing, and that they heard about the outage on social media first. Do not rely on a provider's status page as your first warning. Know what a failed transaction looks like on your terminal, and who on your team will notice first.
6. Decide who decides, and what you will tell customers. Who has the authority to switch to cash only, put a sign on the door, or move a payroll run to another account? Draft the customer message now. It is much easier to write on a quiet afternoon than at eight in the morning with a queue at the counter.
7. Ask your insurer one question. Does your policy cover lost income when a supplier's digital service fails and nothing of yours is physically damaged? Get the answer in writing, and do not assume the answer is yes.

The result does not need to be a long document. For a small business, a short dependency register and a one-page outage card kept by the till will cover the most likely disruptions. For a larger or more complex organisation, the same register is the foundation of a full plan built to ISO 22301, and it is worth testing in a tabletop exercise before an outage tests it for you. If you are deciding how to structure a plan in the first place, I have written about threat-based, activity-based and hybrid approaches.

A note for financial services firms

Financial firms in the EU already have a legal duty to manage this. The Digital Operational Resilience Act (DORA) has applied since 17 January 2025 and requires banks, payment firms, insurers and investment firms to manage the risk that comes from their ICT providers. In November 2025, the European Supervisory Authorities designated 19 providers as critical ICT third-party providers, and Google Cloud has confirmed that its EMEA business is one of them. Designation brings those providers under direct EU oversight, but the regulated firm remains responsible for its own resilience.

Businesses outside financial services are not covered by DORA, but its logic is worth borrowing. Know which of your important functions depend on which providers, and how concentrated that dependence is.

What this morning shows

The Revolut outage did not happen because a café or a small firm in Ireland did anything wrong. It started several layers away, in a building most of the affected businesses will never see, run by a company most of them have no contract with. That is the reason it belongs in a continuity plan. You cannot control your suppliers' infrastructure, but you can know where you depend on it, decide how long you can manage without it, and have a tested way to keep trading when it fails. The shops that could still take payment this morning were the ones that had already decided they might need a second way to do it.

If you would like help mapping your dependencies, or a business continuity plan built to ISO 22301, you can read about DEDICO's business continuity work and the Croke Park case study. Email me at sarah@dedico.ie with a line about your organisation and the outage you would least like to deal with.

Frequently asked questions