Define an SLO for this service and explain the error budget
“You own a checkout API. Define SLIs and an SLO, compute the error budget, and explain how the budget changes what the team does.”
What this tests
- SLI vs SLO vs SLA precisely
- Choosing user-facing indicators and a target that is not 100%
- Error budget arithmetic and burn-rate alerting
- Error budget as a release policy, not a dashboard
Answers by level
Read the beginner answer first and notice what is missing.
An SLI is a measurement: fraction of checkout requests that return a non-5xx within 800 ms, measured at the load balancer where the user sees it. The SLO is the target on that SLI over a window: 99.9% over 30 days. The SLA is a contract with penalties, set looser than the SLO. A health check every minute is not an SLI; it measures whether the process is up, not whether users succeeded.
At 99.9% over 30 days the error budget is 0.1% of requests — for 10 M requests, 10,000 failed or slow requests, or roughly 43 minutes of total failure. The budget is spent by incidents and by risky deploys. When it is healthy, ship fast; when it is nearly spent, the policy says: freeze non-essential releases, prioritise reliability work. That makes the reliability-vs-velocity argument a number instead of an opinion — see Availability, SLOs and Error Budgets.
Green flags · Red flags
- Distinguishes SLI, SLO and SLA in one sentence each
- Measures at the user's edge, with a latency threshold as part of "good"
- Computes the budget in requests and minutes
- Burn-rate alerting with two windows
- Explains the release-policy consequence of a spent budget
- "Our SLO is 100% uptime." or picks 99.99% without knowing it means 4 minutes a month
- SLI = a synthetic health check
- Alerts on thresholds like CPU instead of on user-visible symptoms
- Sees the error budget as a report, not something that changes decisions