SLIs and SLOs

Play this lesson

How reliable is reliable enough?

Priya, who runs observability, asks the team: "How reliable should Shard Garden be?" Kai says: "100%. Always."

Google's SRE book disagrees: 100% is probably never the right target. It can't be reached, and players can't notice the difference beyond a point, because their own phones and networks fail sometimes too. So the team needs a number that is good enough, and a way to measure it.

SLI, SLO, SLA

Shard Garden has no paid contracts, so the studio sets SLOs only.

Quick check

Which of these is an SLA?

  1. A cloud company promising a refund if its uptime falls below 99.9% in a month
  2. Shard Garden aiming for 99.9% of joins to work
  3. The share of saves that finish in under one second
Show the answer

A cloud company promising a refund if its uptime falls below 99.9% in a month

An SLA is a contract with consequences. The second is an SLO, a target. The third is an SLI, the measurement itself.

An SLI is a fraction

Google's SRE workbook recommends one shape for every SLI: good events divided by all events, as a percentage. 0% means nothing works, and 100% means nothing is broken.

Priya's join SLI: joins that put the player in a garden within 3 seconds, divided by all join attempts. The workbook's SLI types include availability, latency, quality, freshness, correctness, coverage and durability. Each player journey picks the types players actually feel.

Pick the SLI

Which SLI best measures "publishing a level in the editor works"?

  1. Publishes that appear in the level browser within 60 seconds, divided by all publish attempts
  2. Average CPU of the editor servers
  3. Number of levels published today
Show the answer

Publishes that appear in the level browser within 60 seconds, divided by all publish attempts

It is good events over all events, and it measures what the player feels: the level shows up, quickly. CPU is a cause, and a raw count has no "good" or "bad".

A window and a target

An SLO needs a time window. The workbook finds a four-week rolling window a good general choice: rolling windows match what users feel, calendar months fit business plans.

Its example: a 99.9% success SLO, with 3 million requests in four weeks, allows 3,000 failures.

The SRE book also advises an internal SLO tighter than the one you tell users, to leave room to fix problems, and warns that users build on how good you really are, not on what you promise.

Do the math

Priya sets the save SLO at 99.9% over four weeks. There were 2 million saves. How many may fail?

  1. 2,000
  2. 200
  3. 20,000
Show the answer

2,000

0.1% of 2,000,000 is 2,000. That allowance is called the error budget, and the next lesson spends it.

Too reliable is a problem too

Google's SRE book tells of Chubby, a lock service many Google systems use. The global Chubby was so reliable that teams added dependencies on it, assuming it would never go down. When it did fail, their services broke.

So SRE makes sure global Chubby meets its SLO but does not greatly exceed it. In any quarter where real failures haven't brought it below its target, they take it down on purpose, flushing out dependencies that shouldn't be there.

Quick check

Google's SRE team takes the global Chubby down on purpose in a quarter where real failures haven't brought it below its target.

Show the answer

True

A planned outage flushes out services that wrongly assume Chubby never fails, while their owners are watching, instead of during a real outage.

Room to break things

A 99.9% SLO means 0.1% may fail. That 0.1% is not just bad luck to put up with. It is a budget the team can spend.

Bolt says: Next: error budgets, and who decides when to stop shipping.

Fact-checked 11 October 2026