What High Availability Really Costs, and What It Buys You

The nines everyone quotes translate to very different real-world numbers. A 99% target allows about 3.65 days of downtime a year, while a 99.9% target allows a little under 8.76 hours, and a 99.99% uptime target allows only around 52.6 minutes¹. The jump between those last two tiers is the one that usually forces a real architecture change, since a budget measured in minutes leaves almost no room for a slow, manual failover process.

Most B2B products with defined business hours and no per-minute contractual penalty can run comfortably at that middle target. Going further is a real engineering investment, and it should be a deliberate choice tied to a specific customer commitment, not a default picked because it sounds more serious.

A standby database replica, a second region, and the automation to fail between them cost money every month whether or not you ever use them, plus the ongoing engineering time to keep the failover path working as the system changes. That is the real price of high availability: not the initial build, but the continuous maintenance that keeps a failover path from silently rotting.

Budget for both when deciding whether the next nine is worth it. A failover system nobody has tested in six months because the team moved on to other work is a liability dressed up as insurance.

The return on investment for redundancy only exists if the failover actually works when triggered for real. Schedule a failover drill on a low-traffic day, treat it like a fire drill, and fix whatever breaks. Most teams find at least one thing wrong the first time they actually try it, a stale connection string, a missing environment variable, a runbook step that assumes a person who left the company.

A drill that surfaces problems on a quiet Tuesday afternoon is doing its job. The alternative is finding those same problems during a real outage, at a much higher cost.

Run the drill in this order:

1. Schedule the drill on a low-traffic day and tell the team it is a fire drill, not a surprise.
2. Trigger the failover the way you would in a real incident, following the written runbook step by step.
3. Note everything that breaks, such as a stale connection string, a missing environment variable or a runbook step that assumes someone who left.
4. Fix each problem, update the runbook, and repeat the drill after any significant architecture change.

If your product is used during business hours by a small number of accounts, a planned maintenance window and a fast recovery process may serve customers better than round-the-clock automatic failover that costs meaningfully more every month. Ask what a customer actually loses during a short maintenance window late on a weekend, and size your investment to that answer, not to a target borrowed from a much larger company's requirements.

For example, consider a product used by a small number of accounts during business hours. Those customers may lose very little during a planned maintenance window late on a weekend, so a well-rehearsed recovery process may serve them better than a costly standby region. The decision rule: write down what a customer actually loses per minute of downtime, compare that with the monthly cost and upkeep of the redundancy, and add more redundancy only when the loss is larger. Revisit the answer when a new contract commits you to a specific uptime target. A common mistake is copying a target from a much larger company without asking whether your customers would notice the difference.

Say your team currently recovers from a regional outage by having an engineer manually redirect traffic and restore from backup, a process that reliably takes forty-five minutes end to end. That works fine against a 99.9% uptime target, which allows a little under 8.76 hours of downtime a year¹, but it would burn through an entire year's downtime budget in a single incident if the target moved to 99.99%, where the whole year's allowance is only about 52.6 minutes¹.

Closing that gap means automating the failover so it takes seconds instead of minutes, which is a meaningfully bigger engineering investment than most teams expect when they first see the target written as a percentage instead of as a number of minutes.