The Cloud Reliance Trap: When Convenience Becomes a Single Point of Failure

Introduction

Last week we watched it happen again. Microsoft 365 and Azure services went down — not for minutes, but for hours — across nearly every region. Train tickets wouldn't open because they arrived via Outlook. NHS hospitals reached for paper records. Traders went back to phones and faxes. And thousands of businesses simply… stopped working.

It's easy to point fingers at Microsoft. But the harder question sits with us: how much of our business continuity have we outsourced to a single provider? And is the convenience worth the risk?

This isn't an anti-cloud rant. It's a cost conversation that every engineering and leadership team needs to have — because the bill for cloud isn't just the monthly invoice. Sometimes it's the outage you never see coming.

The Cost of an Outage Isn't Just "Downtime"

When services go dark, the visible number is "5 hours of outage." The real cost is much harder to calculate and much higher:

• Lost productivity: 10 million affected workers at an average of £30/hour over 4 hours = £1.2 billion in wages paid for zero output
• Missed revenue: Delayed transactions, lost trading opportunities, cancelled client deadlines — some losses are never recovered
• Recovery overhead: Once systems come back, there's the backlog, the catch-up work, the rescheduled meetings. That often costs more than the outage itself
• Reputational damage: When your customers can't work because your tools are down, trust erodes faster than any SLA can repair
• Engineering distraction: Teams scramble to verify systems, explain delays, rebuild confidence — work that was supposed to happen gets pushed aside

The Uptime Institute found that more than 57% of organisations report their most recent major outage cost over $100,000, and one in five exceeded $1 million. And the scary part? Microsoft's subscription revenue barely dipped. You paid — and you still paid — for the service you didn't receive.

The Other Side: What Does Self-Hosting Actually Cost?

So we should all run our own email and file servers, right? Not so fast. Self-hosting has its own price tag, and it's not written on a price list.

The hidden costs of going your own way:

• People cost: Someone has to maintain it. Updates, backups, security patches, monitoring — that's not zero labour. If your senior engineer spends 4 hours troubleshooting a mail server, that's more expensive than the £80/month license you avoided
• Expertise gap: Most teams don't have someone whose job is running a resilient mail platform. Small configuration errors become multi-hour outages of your own making
• Disaster recovery: When your server fails, who do you call? Restoring from backup is easy — unless you don't have a tested one
• Scale limitations: Cloud gives you "infinite until you stop paying." Self-hosting hits a wall. You can't spin up 50 more instances during a traffic spike — you have to buy them first

But the trade-off is control. You decide your uptime. You choose your update schedule. And when something breaks, you don't sit refreshing a status page waiting for someone else to fix it. You own the problem — and the solution.

The Middle Ground Nobody Talks About

Here's where I think most teams get it wrong: it's rarely "all cloud or all self-hosted." It's about criticality and independence.

The smartest move isn't abandoning cloud — it's not letting one provider become your single point of failure. That could mean:

• Running email through one provider and your core systems on another
• Keeping critical workflows documented offline
• Having backup tools for when Teams or email are unreachable
• Self-hosting internal dashboards or knowledge bases that you literally can't work without

Here's Where I'll Probably Start an Argument

I think we've drifted too far toward "someone else's computer" for things that don't actually need to be there. Productivity tools, internal documentation, basic file storage — these are well-understood, predictable workloads. They don't need elastic scaling to 10,000 nodes. They just need to be there when you arrive in the morning.

For those things, the crossover point where self-hosting becomes genuinely cheaper — not just in server costs, but in reliability and independence — is much sooner than we think. A modest server or two running Nextcloud, Mattermost, or a simple knowledge base doesn't need a team of engineers. It needs a sensible setup, good backups, and basic monitoring. And when the global cloud goes dark? Your team still works.

But here's the counterpoint I respect most: cloud outages are highly visible; self-hosted outages are silent and internal. When Microsoft goes down, everyone complains together. When your self-hosted mail server dies at 2am on a Sunday? That phone call is yours. Every. Single. Time.

Over to You

I'd love to hear your team's philosophy on this one.

Where do you draw the line? What stays in the cloud and what — if anything — do you keep under your own roof? And have you ever had that moment where you watched a status page and realised you'd handed your entire working day to someone else's infrastructure? Drop a comment — I'm genuinely curious which side of the trade-off your team sits on.