SLO & Error Budget Vocabulary Exercises

1 / 5

An SRE says: "Our SLO is 99.9% availability, but the SLA with enterprise customers is 99.5%."

What distinguishes an SLO from an SLA?

The three-tier model: SLI → SLO → SLA. The SLO is intentionally tighter than the SLA — engineering targets 99.9% so that even with some error budget consumption, the 99.5% customer commitment is still honoured.

Term	Definition	Example
SLI	Service Level Indicator — the actual measured metric	% of requests returning 2xx
SLO	Service Level Objective — engineering's internal target	99.9% successful requests
SLA	Service Level Agreement — customer contract with financial penalties	99.5% — breach triggers credits

Key vocabulary: SLI/SLO/SLA hierarchy, SLA buffer (gap between SLO and SLA), customer commitment.

2 / 5

An SRE dashboard shows: "Error budget: 43% exhausted this month."

What is an error budget?

For a 99.9% availability SLO: error budget = 0.1% of requests can fail = approximately 43 minutes of downtime per month. If 43% is consumed, 0.043% of requests have failed so far this month — still 57% of the budget remains.

SLO	Error budget (monthly)	Downtime equivalent
99%	1%	~7h 18m per month
99.9%	0.1%	~43m per month
99.99%	0.01%	~4.3m per month

Key vocabulary: error budget balance, budget exhaustion, burn rate.

3 / 5

An SRE alert page shows: "Current burn rate: 2×"

What does burn rate communicate in SRE error budget vocabulary?

Burn rate (from Google SRE): if burn rate = 1, the budget is being consumed at the rate that exactly exhausts it by the end of the window. Burn rate = 2 = budget exhausted in half the window. Used in multi-window alerting strategies.

Burn rate	Meaning	Window to exhaustion
1×	Normal — will exhaust budget at exactly end of window	Full window (e.g. 30 days)
2×	Alert — consuming budget twice as fast as allowed	Half window (e.g. 15 days)
14.4×	Fast burn — budget exhausted in 2 hours (page immediately)	~2 hours

Key vocabulary: multi-window burn rate alerting, fast burn, slow burn, budget runaway.

4 / 5

An engineering manager says: "The team exhausted their error budget — per the SLO policy, they must pause feature work and focus on reliability."

What is the purpose of an error budget policy?

An error budget policy removes per-incident negotiation. The rules are pre-agreed calmly: when the budget is healthy → experiment freely; when it's low → be conservative; when it's exhausted → pause features, focus reliability. This removes ad-hoc friction.

Budget status	Policy action
100% remaining	Experiment freely — deploy, release, innovate
50% remaining	Caution — review deployment risk more carefully
0% remaining	Feature freeze — all effort on reliability and toil reduction

Key vocabulary: reliability vs. velocity trade-off, reliability investment, toil reduction, error budget policy.

5 / 5

An SRE configures: "Alert fires when p99 latency > 500ms sustained for 5 minutes."

Which alerting principle does the "sustained for 5 minutes" condition implement?

Requiring a sustained period (5 minutes) reduces false positives — a brief p99 spike may be a single slow request. Only sustained degradation represents real user pain. This distinguishes symptom-based alerting from cause-based alerting.

Alert type	Example	Noise level
Symptom-based	p99 latency > 500ms for 5 min (user pain)	Low — tied to real impact
Cause-based	CPU > 80% (may not affect users at all)	High — may not matter

Key vocabulary: alert fatigue (too many false positives), SLO-based alerting, alert evaluation window, runbook (response procedure).