SLA, SLO, SLI

Three words people use interchangeably and shouldn’t

These three terms get muddled constantly, and the muddle is expensive because it hides who is on the hook for what. Pin them down:

• SLI — Service Level Indicator. The number you actually measure. “The fraction of HTTP requests that returned a 2xx/3xx in under 300 ms.” It is a ratio of good events to valid events, computed from real traffic. An SLI is a fact.
• SLO — Service Level Objective. The target you hold that SLI to, internally. “99.9% of requests succeed under 300 ms, measured over 28 days.” It is a goal you set yourself. An SLO is a decision.
• SLA — Service Level Agreement. The contract with a customer that says what happens if you miss — usually a refund or service credit. “If monthly availability drops below 99.5%, you get 10% of the month’s fee back.” An SLA is a promise with money attached.

The dependency runs one way: you measure an SLI, you target an SLO, and you promise an SLA. If you don’t have a good SLI, your SLO is fiction and your SLA is a lawsuit waiting to happen. The hook’s team had all three — they just built them on an indicator (“TCP connected”) that had nothing to do with the user’s experience (“checkout worked”).

The nines, and what each one costs

When a stakeholder asks for “five nines,” do you know what you’re agreeing to build — and what it will cost? Availability is usually quoted in “nines” — the percentage of time the service is up over some window. The arithmetic of nines is unintuitive because each extra nine cuts the allowed downtime by 10×, and the absolute numbers get small fast:

availability    downtime/year   downtime/month   downtime/day
99%    (two 9s)    ~3.65 days       ~7.2 hours      ~14.4 min
99.9%  (three 9s)  ~8.76 hours      ~43 min         ~1.44 min
99.99% (four 9s)   ~52.6 min        ~4.3 min        ~8.6 s
99.999%(five 9s)   ~5.26 min        ~26 s           ~0.86 s

Read the month column slowly, because that is the window most SLOs use. At three nines you may be down ~43 minutes a month — one bad deploy and a rollback fits inside that. At four nines you have ~4.3 minutes — a single human paging, logging in, and reacting already blows it, so four nines effectively requires automated failover. At five nines (~26 seconds a month) no human is in the loop at all; you are paying for fully automatic detection and recovery, multi-region redundancy, and the engineering organization to run it. Each nine is roughly an order of magnitude more money and operational maturity than the last — which is why “we want five nines” from a team that deploys manually on Friday afternoons is a budget conversation, not an engineering one.

Why your SLO sits below your SLA

A reliable team never sets its internal SLO equal to the SLA it signed. It deliberately sets the SLO tighter than the SLA — promise the customer 99.5%, target yourself at 99.9%. The gap is a buffer: if you breach your internal 99.9% target, an alert fires and you have room to react before you breach the 99.5% contract and owe refunds. The SLO is the smoke detector; the SLA is the building burning down. If they were set to the same number, the first time you’d learn you were in trouble is when the money was already gone.

There’s a subtler reason too: an SLA is a legal and commercial artifact, often negotiated conservatively and slow to change. An SLO is an engineering dial you tune as you learn what’s achievable and what users actually need. Keeping them separate lets engineering tighten or loosen the target without renegotiating a contract.

The error budget: permission to spend reliability

The most useful idea in this whole area is the inverse of the SLO. If your SLO is 99.9% successful requests, then 0.1% are allowed to fail — that 0.1% is your error budget. Over a 28-day window of, say, 100 million requests, that’s 100,000 requests you may “spend” on failure before you’ve breached the objective.

This reframes reliability from “never fail” (impossible, and the wrong goal) to “stay within budget.” And the budget is a resource you get to spend, which dissolves the classic fight between product (ship features) and SRE (keep it stable). Google’s SRE practice makes this concrete: if there’s budget left, ship; if the budget is exhausted, the policy freezes risky launches and the team spends its effort on reliability until the budget refills. The number does the arguing. A team that’s been flawless all month has budget to burn on a risky migration; a team that just had an incident is in budget debt and should slow down. Crucially, consuming the budget is fine and expected — a perpetually unspent error budget often means you over-invested in reliability the users didn’t ask for and could have spent on features.