It feels like a glitch in reality: your bank will not open, the parcel tracking is dead, a property site is frozen, and social media is filling with people asking the same question — is it just me? Today, 20 October 2026, it is not just you, and it is not a coincidence. A single failure inside a shared piece of internet infrastructure has knocked over services that look completely unrelated.
This explainer covers why so many websites and apps fail together, how these cascade days work, and how to quickly tell what kind of outage you are looking at.
Quick Answer
So many services are down at once because they share the same hidden foundations. Today’s failures trace back to a power event at Google Cloud’s UK region, europe-west2, which hosts or supports banks, delivery firms, and major websites simultaneously. When a shared foundation fails, everything built on it fails together, even though the apps themselves have nothing to do with each other.
The Internet Is a Stack of Shared Foundations
We picture each app as its own independent thing: the bank built its app, the courier built its tracker, the property site built its website. Underneath, though, almost nobody builds the whole stack anymore. Companies rent computing from a handful of cloud providers, rent content delivery from another handful of networks, and plug in shared services for payments, maps, logins, and messaging.
This renting is mostly a triumph. It is why small teams launch sophisticated apps and why services scale on their busiest days. But sharing creates a new shape of risk: the failure of one supplier becomes the failure of every customer at once. Three cloud giants now carry an enormous share of the world’s apps, and a serious problem in one of their regions is a national event, as Britain experienced today when a power event hit Google Cloud’s europe-west2 region and took Revolut, Lloyds, Halifax, DPD, Rightmove and Royal Mail services with it.
Our detailed explainer on what caused the Google Cloud outage that took UK banking apps offline walks through that specific incident step by step; this article is about the general pattern it belongs to.
The Three Ways Outages Cascade
First, direct hosting: the service runs in the failing region, so it simply goes dark. This is the simplest and most common path on a day like today.
Second, dependency chains: a service hosted safely elsewhere still calls a component that is not — a payment processor, an address checker, an identity verification tool sitting in the affected region. The app loads, then fails at one particular step, producing the confusing partial outages where logins work but payments do not.
Third, recovery congestion: when the foundation returns, every affected service and every user retries at once. That thundering herd can knock recovering systems over again, which is why the end of a big outage often flickers — working, broken, working — before it stabilises. Patience during that phase is not politeness; it is literally part of how the recovery succeeds.
How To Tell What Kind of Day It Is
You can diagnose a cascade day in about two minutes:
- Check whether clearly unrelated services are failing for you simultaneously — a bank plus a retailer plus a delivery tracker is the signature.
- Open an outage tracker and look at the front page. On cascade days, the top of the chart is a wall of famous names all spiking together.
- Check the cloud providers’ status pages — starting with Google Cloud’s status dashboard — for a named incident in a named region.
- Glance at the news. Genuine shared-infrastructure failures make headlines within the hour, which also tells you the rough scale and expected duration.
If instead only one app fails and the trackers are quiet, you are having a normal, individual problem, and normal troubleshooting applies. The two situations demand opposite responses: cascade days call for waiting and backups; individual problems call for fixing your own setup.
Why This Keeps Happening
Because the economics point one way. Building on a giant’s cloud is cheaper, faster, and usually more reliable than anything a single company can run itself — until the giant has a bad day, at which point the reliability was shared too. Each individual company made a reasonable choice; the system-level result is concentration that nobody individually chose.
Regulators have noticed. Financial authorities in particular now treat dependence on a few cloud providers as a systemic risk and press big firms on their exit plans and resilience testing. Progress is real but slow, because genuinely independent backup infrastructure is expensive, and for banks the alternative to pausing during an incident — switching systems mid-flight — carries risks of its own that can be worse than downtime.
What To Do on a Cascade Day
Recognise it early and stop troubleshooting — the two-minute diagnosis above is the whole skill. Use the backups that exist outside the failing foundation: physical cards and cash when apps fail, phone calls when web services fail, patience when both wobble. Warn people affected by your delays while the incident is headline news and explanations are believed instantly.
Above all, guard your security. Cascade days are when scam messages about “restoring access” flood in, precisely because everyone is confused and primed to act. The busier the outage, the more boring your response should be: official status pages, official apps, and no links clicked from messages, ever.
The Invisible Layers You Never Hear About
Cloud regions are not the only shared layer. The internet’s directory system, DNS, the certificate authorities that prove a website is itself, and a few giant content-delivery networks all sit beneath thousands of services at once, and each has had its own famous bad day in past years. When one of those layers fails, the pattern is the same as today’s, only wider: perfectly healthy websites become unreachable because the signposting to them broke.
You will never manage these layers yourself, and you do not need to. What matters is the recognition skill: simultaneous failure across unrelated services always means a shared layer, and shared-layer failures are waited out, not troubleshooted. That single idea converts the internet’s worst mornings from personal emergencies into weather.
Common Mistakes to Avoid
- Treating a cascade as personal. Password resets and reinstalls during a shared outage fix nothing and can lock you out properly.
- Trusting the first rumour. Early social posts blame hacks and worse. Status pages and tracker volume are slower and truer.
- Retrying payments repeatedly during recovery. Flickering systems plus impatient retries equal duplicate transactions.
- Assuming unrelated apps means unrelated causes. Unrelated brands routinely share one cloud region. Simultaneity is the clue, not a mystery.
- Having no non-digital fallback. A card, some cash, and one account at a second bank turn cascade days into non-events.
Conclusion
Websites and apps fall together because, beneath their different logos, they stand on the same few foundations. Today’s Google Cloud power event in the UK is the latest demonstration, not an anomaly. Learn the two-minute diagnosis, keep small offline backups, and the next cascade day will find you informed and mildly inconvenienced instead of locked out and alarmed.
Frequently Asked Questions
Is a mass outage usually a cyberattack?
No. The overwhelming majority are ordinary infrastructure failures: power, cooling, networking, or a bad software change. Today’s incident, for example, was a power event at a cloud region, with no indication of an attack.
Why did my app half-work during the outage?
Dependency chains. The parts of the app hosted elsewhere kept running while a component in the affected region failed, so some features worked and others did not.
How long do these cascade outages last?
Typically hours, with recovery arriving in stages and sometimes flickering as everyone reconnects. The provider’s status page gives the most reliable running timeline.
Can companies avoid this completely?
They can reduce exposure with multi-region and multi-provider designs, but cost, regulation, and data-safety rules make total immunity unrealistic. Shorter, rarer incidents are the achievable goal.
What is the single best thing I can do to prepare?
Keep a second way to pay and a small cash buffer. Nearly every practical harm from a cascade day flows through payments, and a backup dissolves it.
Leave a Reply