516 Outages in One Week: The Cascade Risk Hiding in Your Cloud Dependency Chain

In the second week of June 2026, ThousandEyes logged 516 network outages across the global internet. That's not an unusually catastrophic figure — it's roughly an average week. But buried in those numbers is a pattern that should make every UK business owner uneasy: a single failure at one large provider didn't stay contained. It rippled outward, taking down services that had no obvious connection to the original fault.

A law firm in Leeds couldn't send email. The email platform was fine. A retailer in Birmingham found their card payments failing intermittently, even though their point-of-sale provider reported all systems normal. In both cases, the actual culprit sat three or four steps upstream — a content delivery network, an authentication service, a DNS resolver — that both companies used without ever having heard its name.

This is the uncomfortable truth about modern cloud services. You don't buy one thing. You buy a chain of things, and most of that chain is invisible to you.

Uptime isn't a number you own

Ask most SME owners who's responsible for keeping their systems online and they'll point at their provider. Microsoft, AWS, Google, whoever hosts the app they depend on. There's a service level agreement somewhere with a figure like 99.9% on it, and that figure feels like a promise.

It isn't. It's a statement about one link in a chain that might be twenty links long.

Here's how it actually works. Say you run a small accountancy practice on a cloud bookkeeping platform. That platform is hosted on a major cloud provider — fine, that's one dependency. But the platform also uses a separate service to send its notification emails, another to verify your login, a third to store document uploads, and a content delivery network to serve the whole thing quickly. Each of those is run by a different company, on different infrastructure, with different SLAs.

When ThousandEyes tracked the June cascade, the original fault was in a widely used edge and DNS provider. On paper, that provider had nothing to do with your accountancy platform. In practice, your platform's login service routed through it. So when it failed, you couldn't log in — and your bookkeeping provider's status page stayed green the whole time, because their servers were running perfectly.

No single SLA covers this. Your provider's agreement says nothing about the third party whose failure broke your login. And you never signed a contract with that third party at all.

Why cascades stay hidden

The reason these failures feel so baffling is that the dependency is silent right up until the moment it breaks.

Cloud services are built in layers, and each layer trusts the one below it. A developer building your CRM doesn't rebuild email delivery from scratch — they plug in a specialist service. That service, in turn, relies on infrastructure it doesn't own. Nobody in the chain is doing anything wrong. Each choice is sensible on its own. The problem is that the same handful of underlying providers sit beneath thousands of apparently unrelated services.

So when one of those foundational providers has a bad day, it doesn't cause one outage. It causes hundreds, spread across companies that have never met, running software that has nothing in common except a shared dependency they didn't know they had.

That's the shape of a cascade. And it's why the raw outage count — 516 in a week — matters less than the concentration behind it. A relatively small number of root causes accounts for a disproportionate share of the disruption businesses actually feel.

What this means for a UK SME

You can't audit the entire internet, and you shouldn't try. But you can stop treating uptime as someone else's problem and start treating it as a risk you manage — the same way you manage cash flow or insurance.

The goal isn't zero downtime. That's not achievable and chasing it will bankrupt you. The goal is to understand where your genuine single points of failure are, and to make sure a failure anywhere in the chain doesn't stop your business trading.

A café that can still take cash when the card terminal goes down has resilience. A business that grinds to a complete halt because one login service is unreachable does not. The difference is planning, not spending.

A resilience checklist you can act on this week

Here's where to start. None of this requires a big budget — most of it is an afternoon's work and a few honest conversations.

1. List what you can't operate without. Not every system. The three or four that would stop you trading if they vanished for a day. Email, payments, your main line-of-business app, and whatever you use to actually do the work.

2. Ask each provider a direct question. "What third-party services does your platform depend on to function?" Some will answer plainly. Some will be evasive. The evasiveness is itself useful information — it tells you where the risk is concentrated and how seriously the provider takes it.

3. Look for shared foundations. If your email, your file storage, and your CRM all quietly sit on the same underlying cloud region or CDN, you don't have three independent systems. You have one, wearing three coats. Spreading critical functions across genuinely different infrastructure is the single most effective thing you can do.

4. Build a manual fallback for each critical function. How do you take payment if the terminal fails? How do you contact your key customers if email dies? Write it down, one line each. A plan nobody has written is a plan nobody will follow at 9am on a bad Tuesday.

5. Set up independent monitoring. Don't rely on your provider's status page to tell you they're down — they're often the last to admit it. A simple external monitoring service that alerts you when your own site or app stops responding gives you minutes of warning and, crucially, the truth.

6. Check your backups are actually separate. A backup stored on the same platform as the thing it's backing up is not a backup. If the platform fails, so does your safety net. Copies should live somewhere your primary provider can't take down with them.

7. Rehearse once. Pick a quiet afternoon and pretend your main system is offline. Try to keep working using your fallbacks. You'll find the gaps in twenty minutes, and finding them now costs nothing.

The mindset shift

The 516 figure will be a different number next week, and the week after. The specific provider that failed in June will be a different one by autumn. What won't change is the structure: your business rests on a chain you didn't build and can't fully see, and no single contract protects you across all of it.

That's not a reason to panic, and it's certainly not a reason to abandon the cloud. It's a reason to stop assuming resilience comes bundled with your subscription. It doesn't. It comes from knowing your dependencies, spreading your risk, and having a plan for the day the green status page is lying to you.

If you're not sure where your dependency chain actually leads, that's exactly the conversation worth having before the next cascade — not during it.