Engineers love to argue about nines. Three nines, four nines, the heroic push for five. We debate MTTR and error rates and whether the dashboard is green enough, as if reliability were a score to maximize.
The business does not buy nines. It buys revenue that does not evaporate during an outage, customers who still trust you the next morning, and the ability for leadership to not think about whether the site is up. Reliability is a means to those things, and the fastest way to lose a room full of executives is to talk about it as though the nines were the point.
So this is the translation I wish more engineers could do, because it is the difference between defending uptime and being someone the business actually wants making the call. Reliability is a business decision wearing an engineering costume.
Table of contents
Open Table of contents
The short version
- Nobody in the C-suite wants nines. They want the revenue and trust that reliability protects.
- Downtime has a real cost you can compute, and that number decides how much reliability is worth.
- Each additional nine costs roughly ten times more and adds less. Past a point, chasing it destroys value.
- Error budgets are a business tool: they allocate between shipping features and protecting stability.
- Not everything deserves the same reliability. Spend the budget where downtime costs money.
Nobody in the C-suite wants five nines
If you walk into a leadership meeting and ask for headcount and quarters to move from four nines to five, framed as a reliability goal, you will lose. Not because reliability does not matter, but because you asked for the wrong thing. Nobody upstairs wants five nines. They want the outcomes that reliability buys: revenue that keeps flowing, a brand that does not take a hit, and one less thing to worry about.
Nines are the means. Engineers spend so long inside the means that we forget to connect them to the end, and then we are surprised when the business does not fund the means for its own sake.
Downtime has a number, so compute it
The single most useful thing you can do is turn an outage into money, because money is the language the decision gets made in.
cost of downtime per hour =
revenue per hour lost
+ SLA credits and penalties owed
+ customer trust and churn (harder, still real)
+ engineer hours pulled into the incidentWhen you can say “one hour of downtime on the checkout path costs us roughly this much,” the conversation stops being about your opinion of how reliable things should be and starts being about a number everyone can reason over. That number is what tells you how much a given piece of reliability is actually worth buying. Spend more than the downtime costs and you are lighting money on fire to feel safe.
The next nine costs ten times more
Here is the part engineers underweight and executives feel in their gut. Reliability does not scale linearly. Each additional nine of availability costs roughly ten times more to reach than the last, and buys you less.
Going from 99% to 99.9% might be cheap and clearly worth it. Going from 99.99% to 99.999% can mean rearchitecting, multi-region everything, and a small army, to shave minutes of downtime a year off a system where nobody would notice those minutes. That is the shape of the chart above: cost climbing steeply, value flattening, the two crossing at a point past which you are destroying value in the name of engineering pride.
Knowing where that crossing is, and stopping there, is a commercial skill. It is not the impressive-sounding one, but it is the one that separates a leader from an enthusiast.
Error budgets are a business tool
The cleanest way I know to make this concrete is the error budget, and I wish it were pitched to executives more often, because it is a budgeting decision and they are the ones who understand budgets.
An error budget says: here is the amount of unreliability we have decided we can afford. As long as we are within it, we ship features aggressively, because shipping is growth. When we burn through it, we stop shipping and shore up stability, because breaking the promise costs more than the next feature earns. That is an explicit allocation between two sources of business value, growth and protection, and it turns “how reliable should we be” into a tradeoff the business can actually set, instead of an argument engineers have in a vacuum.
Not everything deserves the same reliability
Treating every system as equally critical is how you go broke buying reliability nobody needed.
The checkout flow and the internal reporting tool are not the same business risk, so they should not get the same investment. Tier your systems by what downtime actually costs, and spend the reliability budget where the money is. This is also where a technical leader shows real judgment under pressure. During a serious incident, the right instinct is not to chase the loudest alarm. It is to protect the revenue path and the customer promise first, and let the internal dashboard stay broken a little longer, because one of those is costing money by the minute and the other is costing someone a mild inconvenience.
| Engineers say | The business hears |
|---|---|
| MTTR is down 20% | We recover faster, so outages cost less |
| We hit four nines | Here is the revenue at risk, and what we protect |
| We need to chase five nines | This next step costs 10x and buys almost nothing |
| We spent the error budget | We chose stability over shipping this quarter |
| This system is critical | Downtime here costs money, so fund it |
The most valuable thing you can say
The instinct is to think a technical leader proves their worth by pushing reliability as high as possible. The opposite is true. The most valuable sentence in my toolkit is the one that says stop.
“We should not spend the next three months chasing another nine on this system. It is already reliable enough for what it costs us when it fails, and that engineering time buys far more if we point it at shipping the thing customers are actually asking for.”
Saying no to more reliability, on business grounds, with the numbers to back it, is the signal that you are optimizing for the company and not for your own sense of craftsmanship. Perfection is easy to want. Knowing when it is not worth paying for is the expensive skill, and it is the one the C-suite is quietly listening for.
Final takeaway
Reliability is risk management with a budget attached. That is not a demotion of the engineering, it is what makes the engineering matter, because it ties it to the thing the business is actually trying to protect.
So learn to say it in their terms. Put a number on downtime. Treat the error budget as the allocation decision it is. Tier your systems by business impact and spend accordingly. And be willing to argue, out loud, that a system is reliable enough and the money belongs elsewhere. Do that, and you stop sounding like an engineer defending uptime and start sounding like the person who should be in the room when the real tradeoffs get made.
The nines were never the point. Protecting the business at a price that makes sense always was.