The Cost-of-Downtime Math Before You Over-Build DR

Before you spend a dollar on redundancy, calculate what an hour of downtime actually costs you. Most people skip this and reach straight for hot standbys, multi-region setups, and automatic failover because that is what "serious" infrastructure looks like. Then they pay double for hardware that sits idle to protect against an outage that would have cost them less than the redundancy does. The right amount of disaster recovery is a math problem, not a status symbol. For most self-hosted apps, a scripted restore in an hour is the correct answer, and the expensive stuff is waste.

Calculate the real cost of an hour down

Start with the number everything else depends on. What does one hour of downtime cost this specific app?

• Lost revenue: if the app makes money directly, how much per hour, adjusted for the time of day it is likely to fail.
• Recovery labor: your time or someone else's, cleaning up and restoring.
• Downstream costs: SLA penalties, support load, refunds, churn from users who leave.
• Reputation: real but hard to quantify, so estimate conservatively rather than using it to justify any spend.

For a marketing site, an hour down costs almost nothing measurable. For a content app with ads, it is small. For a payments app at peak, it can be thousands. These are wildly different numbers, and they should drive wildly different DR. The mistake is buying the payments-app plan for the marketing site because both are "production."

Weigh it against what redundancy costs

Now put the other number next to it: what does the redundancy cost, per year, in money and effort?

A hot standby means a second box, always running, always replicating, doing nothing but waiting. You pay for that compute every hour of every day. You also pay in complexity: failover has to be built, tested, and maintained, and automatic failover that is not regularly exercised often fails when it finally triggers, which means you paid for redundancy that did not even work. Complexity is a recurring tax, not a one-time cost.

Set the two numbers against each other. If an hour of downtime costs you fifty dollars and you might have a couple of hours of downtime a year, your annual downtime cost is a hundred dollars. Spending a thousand a year plus ongoing effort on a hot standby to shrink that is a bad trade. You are spending ten dollars to save one. The math says do less.

What "less" looks like, and why it is enough

For the large majority of self-hosted apps, the right DR is not redundancy at all. It is a fast, tested restore.

• Good backups, offsite, following the 3-2-1 rule.
• A scripted rebuild that provisions a fresh box and restores the app in a known amount of time.
• Restore drills that prove the rebuild works and tell you the real recovery time.

If that gets you back up in an hour and an hour down costs you fifty dollars, you are done. You have matched your DR to your risk, and the money you did not spend on a hot standby stays in the business. This is the same reasoning that starts with setting honest RPO and RTO targets: the targets tell you how much recovery to buy, and for most apps the honest targets are generous enough that a simple restore clears them.

When the math justifies more

Sometimes the numbers do point toward real redundancy, and then you build it without apology. If an hour of downtime genuinely costs thousands, if you have SLAs with financial penalties, if the app is the business and being down is existential, then a hot standby and fast failover are worth every dollar because the downtime they prevent costs more than they do. The math works in the other direction, and you follow it.

The point is not that redundancy is bad. The point is that redundancy is a purchase, and you should buy it deliberately, sized to a cost you actually calculated, not reflexively because it feels responsible. I run about twenty companies on my own boxes, and the vast majority run on a simple, tested restore because the downtime math says that is enough. The few that hold real-time customer money get more, because their math says so. Every one of them is a decision, not a default.

I host the whole portfolio on VPS boxes through HostSSH, and the reason it stays cheap is that I match DR to cost. Calculate the hour. Compare it to the redundancy. Buy exactly what the numbers justify and not a dollar more. Over-building DR is not caution. It is unexamined spending wearing a serious face.