Skip to main content

SLI, SLO and error budget

Summary: measuring is not enough — you have to know what level is acceptable. Google's SRE brings three tools: the SLI (the measured indicator), the SLO (the internal objective), the SLA (the contractual commitment). And above all the error budget, which turns reliability into a quantified decision and puts an end to the debates of opinion between development and operations.


1. The three acronyms, distinguished

The distinction to remember for an interview: the SLO is internal (your team's objective, with no contractual consequence), the SLA is external (a contract with penalties). Many candidates confuse them, and the nuance is noticed immediately.

A service can perfectly well have SLOs without any SLA — that is even the most frequent case for a company's internal services.


2. A complete, concrete example


3. The error budget — the most powerful idea in SRE

Here is SRE's truly original contribution. Without an error budget, the conversation looks like this: development wants to deploy, operations finds it "risky", and the decision is made by power dynamics or seniority. With an error budget, the conversation becomes: "we have 31 minutes of budget left this month, we can go" or "the budget is exhausted, we freeze until the 1st of the month". It is no longer an opinion, it is a number.


4. Computing an error budget

Here are the values to know, over a 30-day window.

SLOError budgetTolerated downtime / 30 daysPer week
99%1%7 h 12 min1 h 41 min
99.5%0.5%3 h 36 min50 min
99.9%0.1%43 min 12 s10 min 5 s
99.95%0.05%21 min 36 s5 min 2 s
99.99%0.01%4 min 19 s1 min
99.999%0.001%26 s6 s

What this table immediately reveals: going from 99.9% to 99.99% reduces your room for maneuver from 43 minutes to 4 minutes per month. That means a single failed redeployment consumes your entire monthly budget. That is why each additional "nine" costs exponentially, not linearly.

A question to ask before aiming for 99.99%: "are we capable of detecting and fixing an incident in under 4 minutes?" If the answer is no, that SLO is not achievable and has no point.


5. Why aiming for 100% is a mistake

Reason 3 is the most convincing argument in front of management demanding "zero outages". If your users are on mobile, with a connection that is 99% available, your effort to go from 99.9% to 99.99% is literally imperceptible to them. The money would be far better invested elsewhere.


6. How to define a good SLO

Step 5 is the one that fails most often, and it is decisive. If your product leadership considers that "any downtime is unacceptable", your error budget will have no decision-making power. The SLO must be an explicit agreement between engineering and the business, not an internal technical document.

Step 6 is the one that gets forgotten. Deciding calmly in advance what will be done when the budget is exhausted avoids a negotiation under pressure, at a moment when nobody is in a state to reason serenely.


7. The budget burn rate

This is the modern way to alert, and it is far superior to fixed thresholds.

Why this approach has replaced fixed thresholds: an alert of the type "the error rate exceeds 1%" fires for a thirty-second anomaly with no consequence. An alert of the type "at this pace, we will exhaust our monthly budget in seven hours" only fires when it really matters. It is the most effective remedy against alert fatigue.

Commonly recommended configuration: two alerts, one at a rate of 14.4 over one hour (urgent handling) and one at a rate of 6 over six hours (handled during business hours).


8. The classic mistakes with SLOs

Mistake 4 is fatal to the approach. If the team observes that the freeze is never applied, the error budget becomes a decorative indicator. It is better to have no SLO than to have one whose consequences nobody respects — it discredits the approach for years.


Remember in 30 seconds

  • SLI = the measured indicator. SLO = the internal objective. SLA = the contractual commitment with penalties.
  • Golden rule: the SLO must be stricter than the SLA, to keep a margin.
  • Error budget = the complement of the SLO. It is a resource to spend, not a regrettable tolerance.
  • With an SLO of 99.9%, your budget is 43 minutes per month. With 99.99%, only 4 minutes.
  • Each additional "nine" costs about ten times more than the previous one.
  • Aiming for 100% is a mistake: impossible, exponentially expensive, imperceptible to the user, and paralyzing.
  • The error budget ends the conflict between development and operations by replacing opinion with a number.
  • Alert on the budget burn rate, not on fixed thresholds. It is the best remedy for alert fatigue.
  • Start with a single SLO on your most critical journey, and validate it with the business.
  • If the freeze is never applied when the budget is exhausted, the SLO serves no purpose.

Next: The tools and the art of alerting →