8.3 Availability, SLOs and error budgets

What this is and why it exists

"It should always be up" is not a target, it is a wish, and a team working towards it makes worse decisions than a team working towards a number. This lesson replaces the wish with arithmetic: what you are measuring, what you are promising, how much each additional nine actually demands of you, and how to spend the failure you have allowed yourself instead of pretending you have none.

The vocabulary

• SLI (service level indicator) — the thing you measure: the proportion of requests that succeeded quickly enough.
• SLO (service level objective) — the target you set for that indicator, internally.
• SLA (service level agreement) — the promise made to a customer, with a consequence attached.
• Error budget — the amount of failure your objective permits, treated as a quantity you may spend.
• Nine — one more 9 in an availability figure: 99.9 to 99.99.
• Graceful degradation — losing a feature rather than the whole service.

The mental model

The three terms differ by audience. The indicator is for the system: a measurable ratio, usually good requests divided by total requests over a window. The objective is for your team: the level you have decided to hold. The agreement is for a customer, and it is a contract — which is why the SLA figure is always weaker than the internal objective, so that missing your own target is a conversation rather than a breach.

Then the arithmetic that makes availability real, and the only form worth quoting is minutes. Take a thirty-day month as forty-three thousand two hundred minutes. Ninety-nine percent allows one percent of that, which is four hundred and thirty-two minutes — a little over seven hours a month. Ninety-nine point nine allows a tenth of that: forty-three minutes. Ninety-nine point nine nine allows four point three minutes. And ninety-nine point nine nine nine allows about twenty-six seconds a month.

Read those figures next to the work each one demands and the cost of a nine becomes concrete. Seven hours a month tolerates a single region, an ordinary deployment and a person who fixes things during office hours. Forty-three minutes rules out most manual intervention — nobody is woken, diagnoses and fixes inside forty-three minutes, monthly — so it requires redundancy that fails over on its own. Four minutes is shorter than most people take to read an alert, so every recovery must be automatic and every deployment must be reversible without a human decision. Twenty-six seconds means no human is in any loop at all, and it usually means multiple regions, which changes the data architecture, the testing, the cost and the team. Each nine is not ten percent more work; it is a different system.

Which is why the number should be chosen from what users need rather than from ambition. Ask what actually happens to somebody when the service is down for ten minutes. For a student's revision plan, they come back later and nothing is lost. For a payment system, money and trust are. Those two deserve different targets, different architectures, and different amounts of somebody's weekend, and pretending otherwise is how teams spend a year on reliability nobody asked for.

The error budget is the idea that converts all this into decisions. If your objective is 99.9, you have forty-three minutes of failure a month and they are yours to spend. Spend them on releases: ship often while the budget holds, and when it is exhausted, stop shipping features and spend the time on stability instead. That turns the eternal argument between speed and safety into a rule both sides can read off the same number — and it also legitimises the other direction, because a budget going permanently unspent means the target is stricter than it needs to be and you are paying for reliability nobody values.

Finally, degrade rather than fail. Most systems can lose something without losing everything: serve the cached version when the database is slow, hide the recommendations panel when its service is down, accept the submission and process it later. Every one of those is a deliberate decision made in advance about what is essential, and it is what turns a total outage into a diminished experience. It is also, in practice, how a modest number of nines is reached without a heroic architecture — not by never failing, but by failing in a smaller place than the whole product.

What you should now be able to explain or do

Distinguish indicator, objective and agreement by audience, and say why the agreement is the weakest figure. Convert an availability percentage into minutes a month without notes. Say what each of the four common targets demands of a team. Choose a target for a described product from what users lose, and defend it. Explain how an error budget settles the release-speed argument in both directions. Give three ways a system can degrade rather than fail.

Check yourself