What the "nines" actually mean
Availability is usually quoted in "nines": 99.9% is three nines, 99.99% is four, 99.999% is five. Each extra nine looks like a rounding error on paper, but it is really a factor-of-ten promise about how little time your service is allowed to be down. Three nines sounds almost perfect, yet it still leaves roughly 8 hours and 46 minutes of downtime a year, about 44 minutes a month. Four nines cuts that to under 53 minutes a year; five nines to just over 5 minutes. The calculator above turns whatever target you pick into those concrete numbers so the conversation stops being abstract.
The reason the jump between nines matters so much is that each one is roughly ten times harder, and more expensive, to hold. Going from 99.9% to 99.99% is not "a bit more testing"; it usually means redundant infrastructure across availability zones, automated failover measured in seconds rather than minutes, and enough instrumentation to detect a problem before a customer does. If you are weighing what that investment actually buys, our primer on what SRE is explains how reliability targets translate into engineering work, and the SRE engagement page shows how we run them in production.
Picking a target is therefore a cost-versus-reliability decision, not a vanity metric. The right number is the point where the revenue, contractual penalties or user trust you protect with the next nine exceeds what it costs to hold that nine. For most B2B SaaS, that lands at 99.9% or 99.95% for the core product, with tighter targets reserved for the handful of endpoints where downtime is genuinely expensive. We walk through that reasoning specifically for subscription products in SRE for SaaS, and you can pair this tool with the cloud waste calculator to weigh reliability against the spend side of the same tradeoff.
Turn the SLA into an error budget
Once you have a target, the allowed downtime is far more useful as a budget than as a threshold. If your SLO is 99.9%, you have about 43 minutes of unavailability to spend each month. That is your error budget: every incident, bad deploy, failed migration or flaky dependency draws it down, and when it is gone you have, by definition, missed your target for the month.
Framing reliability this way changes how teams behave. When the budget is healthy, you can ship aggressively, run risky migrations and take on experiments, because you have room to absorb the occasional failure. When the budget is nearly spent, the same policy tells you to freeze risky changes and put engineering time into resilience instead. The SLA stops being a pass/fail line that only matters after an outage and becomes a resource the team manages week to week. Observability is what makes the budget measurable in the first place; if you are still standing that up, what is observability covers the signals you need to see the budget draining in real time.
Error budgets also protect people, not just uptime. Chasing an unrealistic target, or treating every alert as a budget-threatening emergency, is a fast route to burnout and pager noise. We wrote about how that plays out, and how to avoid it, in the alert fatigue trap. And if you add a revenue-per-hour figure to the calculator, you can see the budget in money: the annual cost of the downtime your target permits, which is often the single number that gets a reliability investment approved.