How many nines do you need?

Every nine is a purchase. 99% availability tolerates about three and a half days of downtime a year; 99.9% about eight and a half hours; 99.99% under an hour; 99.999% five minutes, which is less time than most teams need to acknowledge a page. The engineering required does not scale linearly with the nines. It scales roughly tenfold per digit, and the digit is usually chosen by someone who will not pay for it.

Who chose the current number, and what did they know?

This is a diligence question, and we ask it verbatim. The answers sort into three piles. Sometimes a real commitment exists: a contract with penalties, a regulator, an upstream dependency of someone else's promise. Sometimes the number was inherited from a template ("four nines" sounds like seriousness). And sometimes, arguably the healthiest case, nobody chose; the system delivers what it delivers and the org has been lucky enough not to notice. Only the first pile justifies spending. The other two justify a conversation.

What does each nine actually buy the business?

Work backward from the user. A B2B product used during business hours has perhaps 2,000 meaningful hours a year; downtime at 3 a.m. Sunday is invisible, and an unavailability budget spent entirely inside business hours is a different promise than the same number spread evenly. This is why we push clients from "nines" toward error budgets in the SRE tradition: a budget states what you will spend, where, on what. A nine states a mood.

The cost side compounds structurally, not just financially. The fourth nine typically demands a second region, with everything that entails: consensus machinery, failover rehearsals, data replication whose own failure modes have caused some of the industry's most public outages. You buy availability with complexity, and complexity is purchased with the same currency outages are made of. There is a crossover point, different for every system, where the machinery of the promise becomes the leading cause of breaking it.

What would we sign?

Our advice, given with the usual caveat that your contract may already have signed for you: measure what you actually deliver today, from the user's side, per critical path rather than per service (the path is what the promise rides on). Set the target one notch above the worst month that the business found acceptable in hindsight. Fund the gap explicitly. And write down what a miss costs, because an availability target without a consequence is a wish, and wishes do not survive capacity planning.

The systems we respect most rarely advertise five nines. They advertise a number their team can explain, deliver it through boring machinery, and renegotiate it in daylight when the business changes. That is what a promise looks like when someone intends to keep it.