99.

I was sitting in a sprint planning meeting last week when our PM started pushing for "five nines" availability for a new internal tool we're deploying. My immediate reaction was to look at our budget and then at our current on-call rotation, because chasing that level of reliability is a massive trap if you don't know the math. Most people hear "99.9%" and think the service is basically immortal, but in a real-world deployment, that translates to about 43 minutes of downtime per month. If your team is still manually restarting services at 3 AM, you'll blow through that 43-minute budget in a single bad deployment.

When we are looking at these numbers, the scale of the "nines" changes everything. It's not a linear progression; it's an exponential climb in difficulty and cost.

• 99% (Two nines): You're looking at over 7 hours of downtime a month. This is basically "we have a backup and we'll fix it when it breaks."
• 99.9% (Three nines): This brings you down to roughly 43 minutes a month. This is the sweet spot for most B2B SaaS products and internal tools.
• 99.99% (Four nines): Now we're talking about only 4 minutes of downtime a month. This requires serious automation.
• 99.999% (Five nines): You get about 26 seconds of downtime a month. This is "don't even blink" territory, usually reserved for core banking or medical systems.

The jump from 99% to 99.9% is actually one of the most efficient moves a team can make because you're shaving days off your yearly downtime for a relatively reasonable engineering effort. But once you try to move from 99.9% to 99.99%, the complexity explodes. You can't just have a spare server sitting in a rack. You need full redundancy across different geographic regions, automated failover that actually works without human intervention, and a CI/CD pipeline so tight that a bad release is statistically improbable.

In my experience, the biggest mistake teams make is confusing their SLA with their SLO.

An SLA (Service Level Agreement) is the legal promise you make to customers—usually involving money or credits if you fail. An SLO (Service Level Objective) is the internal target your engineers actually aim for. If your SLA says 99.9%, your SLO should probably be 99.95%. You need that buffer. If you aim exactly at the SLA, a single minor hiccup puts you in a position where you're either breaking a contract or burning through your error budget immediately.

The real question isn't "can we build it?" but "should we build it?" You have to treat availability as a business decision. I always tell my leads to calculate the actual cost of an hour of downtime. If a service goes dark and it only costs the company a few hundred bucks in lost productivity, spending $50k a year on multi-region high-availability architecture is a terrible ROI. If that same hour of downtime costs $50,000 in lost transactions, then chasing those extra nines is mandatory.

Don't let the pursuit of perfection kill your velocity. Pick a target based on the actual cost of being down, not based on what sounds impressive in a marketing deck.