Last Wednesday, GitHub went down. Again. Not a full outage—just pull requests and issues. But if you’re a developer, you know that feeling: the sudden cold sweat when you can’t open a PR, the idle chat messages asking ‘is it just me?’, the helplessness of watching a status page update every 5 minutes.
And then the inevitable comment from the guy who defends the cloud: ‘You need to use cloud services because the uptime can’t be matched if you run it yourself.’ He’s right. But not in the way he thinks.
The thing about 99.99% uptime is that it’s a statistical guarantee that you will be screwed—just not every day.
Let’s be honest: the cloud is amazing. It abstracts away servers, scaling, and patching. You get instant global distribution. But that convenience comes with a hidden cost: you surrender the ability to know, diagnose, or fix the failure when it happens. And it will happen. GitHub has had more than 30 incidents this year alone. AWS, Azure, GCP—they all have their ‘regional degradations.’ Every time, the same pattern: a status page, a vague ‘we’re investigating,’ then silence.
I spoke to a startup CTO who lost a full day of productivity because Azure had a routing issue. He couldn’t even SSH into his own databases. His team sat idle. The cloud provider’s SLA meant he got a 5% credit on his bill—about $12. That’s the compensation for a day of lost revenue, customer trust, and developer sanity.
Here’s the paradox most people miss: the cloud’s unmatched uptime is built on centralization. Massive data centers, shared infrastructure, single control planes. That architecture is what makes the 99.99% possible—and also what makes the failure catastrophic. When a self-hosted server goes down, you can log in, check logs, reboot, call your ISP. When the cloud goes down, you refresh the status page. That’s it.
You’re not paying for uptime. You’re paying for the privilege of being helpless when things go wrong.
Self-hosting isn’t perfect. It’s messy, requires skill, and can fail just as often—but differently. The failure modes are local, not global. You can mitigate. You can learn. You can, most importantly, stay in control. The cloud’s failure mode is a black box. You don’t know if it’s a DNS problem, a routing bug, a database corruption, or a DDoS. You just wait.
So why do we keep falling for it? Because the numbers look good. 99.99% uptime sounds like 52 minutes of downtime per year. But that’s an average. Real incidents don’t obey averages. They cluster. They cascade. And when they hit, they hit the exact moment you need the system most—like that version release or that critical customer demo.
Here’s the truth: the cloud’s uptime is a statistical mirage. It’s a trade-off, not a solution. If you’re building a business on a single cloud provider, you’re not resilient—you’re just in a nicer dependency.
Stop pretending the cloud’s uptime promise is unconditional. Start designing for failure. Use multiple clouds. Keep offline backups. Have a runbook that doesn’t rely on a status page. Or, and this is the real contrarian move, go back to hosting your own critical infrastructure. It’s not 1999. You can do it. And when it breaks, you’ll know exactly what to do.
Self-hosting isn’t about uptime. It’s about owning your failure.
Next time you see that ‘unmatched uptime’ claim, remember the GitHub incident. Remember the 30 minutes of refreshing a page, the Slack messages, the helplessness. The cloud works almost all the time. But when it fails, it fails exactly when you can’t do anything about it. And that’s a trade-off you need to stop pretending is acceptable.
FAQ
Q: But isn't cloud uptime actually better than self-hosting for most companies?
A: Statistically yes, but the risk is not just downtime—it's loss of control, inability to diagnose, and compounding failures. The question is not whether it's better, but whether the trade-off is worth it. For many, the answer is 'no' once they experience a real cloud outage.
Q: What practical steps can I take to avoid this vulnerability?
A: Design for failure. Don't rely on a single cloud provider. Use multi-cloud or hybrid architectures. Have offline backups, local fallbacks, and runbooks that don't depend on the provider's status page. For mission-critical services, consider self-hosting or at least implement an independent monitoring layer.
Q: Isn't self-hosting even more unreliable than using a cloud provider?
A: It can be, but you own the failure. With cloud, you're paying for the privilege of being helpless when things go wrong. The real solution is to demand better transparency and fault tolerance from providers. Self-hosting forces you to be proactive, and that often leads to more resilient systems in the long run.