SLI vs SLO vs SLA: promising reliability you can measure

After the high-availability review, Meera Kulkarni can tell investors how much downtime SeatJaldi’s design allows. Then one investor asks a simpler question. “What counts as up?”

The 22-minute outage during the national final sale was clearly down. But last Thursday, tapping Book took about 6 seconds. The app answered every tap, and many fans gave up. Was SeatJaldi up?

Arjun Nair says yes, the servers answered. Zoya Mirza says no, fans could not book. Arjun’s fix: “Set the target at 100%. Anything less looks weak.” Sandeep Patil, dry as ever, asks what that does to the first deploy anyone ships.

“What do I promise?” Meera asks. “And if we miss?” Sandeep writes a target on the whiteboard: 99.9% of bookings good. Over 28 days that allows about 40 bad minutes, and the outage alone took 22. How much is left, and what happens when it runs out? Right now, they would only be guessing.

An SLI is the number you measure, an SLO is your target for it, and an SLA is a promise to customers with a penalty.

Sandeep’s SLI is the share of booking requests that succeed within 1 second. For fans, Thursday was not up.

His SLO is 99.9% good over a rolling 28 days, always the last 28 days. The SLA, the promise with a penalty from the last lesson, sits looser. Say SeatJaldi promises event organisers 99.5%, with a fee refund if it misses (assumed).

Joseph’s few slow pizzas show the one line to keep: reliability is a budget you are allowed to spend.

• A delivery app promises “30 minutes or a coupon”. The minutes are measured, and the coupon is the penalty.
• A status page shows “99.95% over the last 90 days”. Someone decided what counts as up, measured it and published it.
• A company pauses new features for a week to fix stability. It had spent its allowance for failure, so its rule said slow down.

An error budget is the gap between your SLO and 100%: the failure you may spend on outages and risky deploys. Joseph’s few 27-minute pizzas, slower than his goal but inside his promise, are his budget.

Zoya writes the rule before anyone needs it. While budget is left, the team ships as usual. Once it is spent, risky deploys pause and reliability comes first. That written rule is the error-budget policy. Because the window rolls, old bad minutes drop out after 28 days.

A good SLO measures something users feel, such as bookings that succeed within 1 second. Joseph counts hot pizza at the door, not his oven’s temperature.

• Bad SLI: “CPU is under 40%.” The CPU, the machine’s processor, is a cause; bookings can fail while it is calm.
• Bad SLI: “The server is up.” On Thursday the server answered, and fans still left.
• Good SLI: good booking requests out of all booking requests, counted from the fan’s side.

Pick SLIs from the user’s side, keep the SLO below 100% and above the SLA, and agree early what happens when the budget runs out.

• Keep a handful of SLIs, and define “good” exactly: a status code below 500, so no server error, within 1 second.
• Set the target from what users need, not from what you hit today.
• Track the latency of failed requests separately, or fast errors make latency look healthy.
• Use whole weeks: 28 days always holds 4 weekends, so busy Sundays count the same.

Mind the margin. Meera’s assumed SLA of 99.5%, with a fee refund if missed, allows 0.5% × 40,320 = 201.6 minutes in the same 28 days. That is five times the team’s 40.32. As lesson 28 showed, “designed for” is a goal; only an SLA carries a penalty.

Engineers also watch how fast the budget drains.

If every booking fails, that is 1,000 times the allowed 0.1%, a burn rate of 1,000. A full 40.32-minute budget is gone in 40.32 minutes. If 1% fail, the rate is 10 and the budget lasts 2.8 days.

What just happened? Good requests divided by all requests, times 100, in PostgreSQL-style SQL. With 10,000 mocked rows, 6 failed and 4 slow, it returns 99.9. With no rows, it returns one row holding NULL, an empty value, instead of a divide-by-zero error.

Here only server errors, codes 500 and up, count as failed. Decide on purpose whether a 429, which turns a fan away, should count as bad too. Real systems keep running counts rather than reading every row.

Zoya’s policy follows the example in Google’s site reliability workbook. Once the budget is spent, deploys stop except urgent and security fixes. Any outage that eats over a fifth of it, about 8 minutes, gets a written review with at least one fix. The outage qualifies.

Try it yourself

1. 1

   Write the SLI

   For the booking API, write one sentence: what share of which requests counts as good?

2. 2

   Set the SLO

   Use 99.9% over a rolling 28 days, the SLO Sandeep chose.

3. 3

   Do the budget

   Work out 28 × 24 × 60 × 0.001 minutes, then the share a 22-minute outage uses.

4. 4

   Check

   You are right if your SLI is good requests out of all requests and the budget is 40.32 minutes. The outage uses about 55%, leaving about 18.

Back to the whiteboard: 40.32 − 22 leaves 18.32 minutes. That is the minutes view; counted in bookings, a peak-sale outage spent far more of it. Deploys go out carefully now, and if the budget runs dry, risky ones pause until enough old bad minutes roll out of the 28-day window.

Meera’s investor slide has three sentences. “We measure the share of bookings that succeed within one second. We aim for 99.9% over 28 days and promise organisers 99.5%, with a fee refund if we miss. If we miss our target, new features pause until reliability is fixed.” Like Joseph, she aims tighter than she promises.

Thursday has an answer too: those 6-second bookings were bad minutes. To measure this, Sandeep needs to see inside the system. There were dashboards everywhere, yet nobody saw the last outage coming.