SLIs, SLOs, error budgets and burn-rate alerts

Count good over valid events, target below 100%, and spend the gap as a budget: page on a fast burn, ticket a slow one.

Before you read: predict

ExamHall counts an autosave attempt as good when the server acknowledges it within 1 s, and counts only attempts made inside an exam window. Its objective is 99.95% good over a rolling 30 days, and the 30 days are expected to hold 72,000,000 such attempts. In the 09:00–10:00 exam-start hour, inside the exam windows, the log shows 900,000 attempts: 895,950 acknowledged within 1 s, 3,150 acknowledged later and 900 that failed.

What share of the 30-day error budget did that hour spend?

The 30-second version

An SLI is good events ÷ valid events, where "good" names what the user needed. An SLO is its target over a window, below 100%. The error budget is the bad events it allows: (1 − SLO) × the window's valid events. Burn rate is the error rate ÷ (1 − SLO). Page when a long and a short window burn fast; ticket slow burns.

Count good over valid events, target below 100%, and spend the gap as a budget: page on a fast burn, ticket a slow one.

How it works

Step 1 of 13

SLI. A ratio of events: good ÷ valid. "Good" names what the user needed, such as an autosave acknowledged within 1 s.

In the kitchen

"roads gritted before they ice" is what drivers need → the good event (step 1)

Analogy: A county depot's road salt for the winter (winter road maintenance)

The council funds one barn of road salt for the season and accepts that, some nights, a road ices before a gritter arrives.

At the depot	With an SLO
"roads gritted before they ice" is what drivers need	the good event (step 1)
no road is ever allowed to ice, so no lorry may be serviced in winter	a 100% target (step 4)
the barn holds what the season allows	the error budget (step 5)
a storm night across the whole county uses more salt than a quiet night on a few roads	spend counted in events (step 6)
at the planned nightly pace the barn empties on the last day of winter	burn rate 1 (step 7)
the manager is phoned at night only if a cold snap would empty the barn within days, and it is still freezing now	a page on a long and a short window (steps 11–12)
a month of slightly heavy spreading goes on Monday's report	a ticket (step 13)

Breaks down when: salt is spent to prevent harm, while the error budget is harm users have already had; nobody refills it, and it frees only as old bad events leave the rolling window.

Contrasting case: a contract that refunds a customer when service falls short is an agreement (an SLA), not the target the team steers by.

In real terms: count good over valid events, allow a small share of bad ones, and alert on how fast that allowance is going.

Examples, run for real

4.1 ExamHall EXH-2590: woken for blips

Autosave paged whenever 10 minutes' error ratio reached 0.05%, its 1 − SLO. One synthetic exam day (seeded):

4.1 seed 2590 · exam day 08:00-18:00 · 5,000 attempts a minute · 6 blips of 2 min at 1% failed (08:26, 09:23, 10:22, 11:26, 15:38, 16:28) · one outage 13:30-13:38 at 30%
4.1 old rule (10-min error ratio >= 0.05%): 7 pages (08:27, 09:24, 10:23, 11:27, 13:31, 15:39, 16:29)
4.1 the 30 days hold 90,000,000 attempts: budget 45,000 bad attempts · each blip spent 100 (0.22%) · the outage spent 12,000 (26.67%)
4.1 MR !2890 rule (1 h and 5 min over 14.4, or 6 h and 30 min over 6): 1 page, at 13:32

Each blip spent a sliver of the budget but woke someone (step 9); the outage was the only event that threatened the objective. MR !2890 replaces the rule with burn-rate pages over a long and a short window (steps 11–12), which page once, for the outage.

4.2 Payments ledger: what a burn rate means

For a 99.9% objective over 30 days, at steady traffic:

4.2 burn rate 1 · error rate 0.1% · budget gone in 30 days · one hour spends 0.14%
4.2 burn rate 2 · error rate 0.2% · budget gone in 15 days · one hour spends 0.28%
4.2 burn rate 10 · error rate 1% · budget gone in 3 days · one hour spends 1.39%
4.2 burn rate 14.4 · error rate 1.44% · budget gone in 2.08 days · one hour spends 2%
4.2 burn rate 1000 · error rate 100% · budget gone in 43.2 minutes · one hour spends all of it

Each row follows from step 7: the budget lasts the window ÷ the burn rate, and an hour spends burn rate ÷ 720 of it (step 8).

Try it

Answer first, then check. Nothing is saved.

Question 1 of 6

A ticket shop counts a checkout request as good when the order is confirmed within 2 s, and counts only requests sent from buyers' browsers. One day's checkout log holds 40,000 requests, 2,000 of them from the shop's uptime checker, each confirmed within 1 s. Of the buyers' requests, 37,440 were confirmed within 2 s, 370 were confirmed later and 190 failed.

What was the day's SLI, to two decimal places?

Question 2 of 6

A payments ledger's objective is 99.9% of postings good over each calendar month of 30 days, counted from the 1st, and postings arrive at the same rate every day. From the 1st to the end of the 7th, 0.35% of postings failed, the same share each day.

If that error rate holds, on which day does the budget run out?

Question 3 of 6

A video service's playback objective is 99.95% over 28 days, with the same number of plays every hour. The team wants a page when one hour of errors has spent 2% of the 28-day error budget. Its rule reads playback_error_ratio_1h > X.

What is X, as a percent to two decimal places?

Question 4 of 6

ExamHall's head of product asks for the results-release service's objective to be 100% of result pages served within 2 s, because a candidate who cannot see a grade on results morning is badly let down. Last term the service reached 99.99%. The platform ships a release most weekdays.

Which target do you propose?

Question 5 of 6

A payments ledger's objective is 99.9% of postings confirmed over a rolling 30 days, and postings arrive at the same rate every minute. Its page rule fires while the burn rate over the last hour and the burn rate over the last 5 minutes are both above 14.4, and it is checked at the start of every minute. No posting had failed for a day when, from 14:00, 20% of postings failed. At 14:15 the fault was fixed, and none failed after that.

When does the page stop firing?

Question 6 of 6

A music-streaming service's objective is 99.9% of plays starting, measured across a rolling 30 days, with the same number of plays every minute and, at random, about 1 play in 20,000 failing. Two faults from last quarter are replayed against candidate alert rules, one at a time, each after 30 quiet days: a CDN fault that made 40% of plays fail for 20 minutes, and a codec bug that made 0.15% of plays fail for 4 days. The team wants the CDN fault to wake the on-call engineer within its first hour, and the codec bug to reach the team's working-hours queue within its first 3 days without waking anyone. In each rule, the number after a window is a burn rate across that window.

Which rule set does all of that?

Go deeper

Pro tips

Before trusting a burn-rate page on a quiet service, count how many failures it takes: at 10 requests an hour, one failure is a 10% error rate. When: a low-traffic endpoint, or a service at night, pages for a single failed request (workbook, "Low-Traffic Services"). Verify: tip 99.9% over 30 days · 10 requests in an hour, 1 failed · burn rate 100 · that hour spent 13.89% of the budget Status: RAN.

Source

Both are the curriculum row's named sources. The SRE book and workbook are published texts that Google may revise: the facts below are as of 2026-10-02. Valid as of 2026-10-02.

Google, Site Reliability Engineering, ch. 4 Service Level Objectives: https://sre.google/sre-book/service-level-objectives/ (sre-slo.txt). Quoted: an SLI is "a carefully defined quantitative measure of some aspect of the level of service that is provided"; an SLO is "a target value or range of values for a service level that is measured by an SLI"; "It’s both unrealistic and undesirable to insist that SLOs will be met 100% of the time"; "it is better to allow an error budget—a rate at which the SLOs can be missed"; the gap between the violation rate and the budget is "used as an input to the process that decides when to roll out new releases"; "Don’t pick a target based on current performance"; "Avoid absolutes"; "You can always refine SLO definitions and targets over time".
Google, The Site Reliability Workbook, ch. 5 Alerting on SLOs: https://sre.google/workbook/alerting-on-slos/ (workbook-alerting.txt). Quoted: "SLIs that capture the ratio of good events to total events. The error budget gives the number of allowed bad events"; "Burn rate is how fast, relative to the SLO, the service consumes the error budget"; burn rate 1 leaves "exactly 0 budget at the end of the SLO’s time window"; the raw-threshold rule "would alert, while consuming only 0.02% of the monthly error budget"; a duration clause "resets" when the metric "even momentarily returns to a level within SLO"; "2% budget consumption in one hour and 5% budget consumption in six hours as reasonable starting numbers for paging, and 10% budget consumption in three days as a good baseline for ticket alerts"; "make the short window 1/12 the duration of the long window"; "If an issue will exhaust the error budget within hours or a few days, sending an active notification is appropriate. Otherwise, a ticket-based notification". Supports steps 2, 5–13 and the tip. Its low-traffic example says one failure in 10 requests "constitutes a 1,000x burn rate" while giving "13.9% of the 30-day error budget", which a burn rate of 100 produces (10% ÷ 0.1%); the tip uses the executed 100.

Checked against the tools and docs as of 2026-10-02.

Predict first