TL;DR: SLI is the measurement, SLO is the target you set on it, SLA is the contract with a penalty. For a time-based SLI over 30 days, 99.95 percent permits 21.6 minutes bad. For a request-based SLI it permits 0.05 percent of eligible requests; traffic distribution determines the corresponding outage duration. Spending it should change release policy, not just trigger a chat message.
How to approach it
One line per definition, the arithmetic spoken aloud with no hedging, and then the bulk of your time on the third part. Definitions are the marks everybody collects. What the budget is actually for is what separates people who have run this from people who have read the book.
A strong answer
An SLI is a measured indicator of service health, expressed as a ratio a user would recognise: successful requests over total requests, or requests served under 300 milliseconds over total. An SLO is a target on that indicator over a window, such as 99.95 percent of requests successful over 28 days. An SLA is a contract that says what the customer gets when you miss, usually a service credit, and teams often set an internal SLO above the contractual target to create operating margin, but that ordering is a policy choice.
For the time-based example, the arithmetic is: 30 days is 43,200 minutes. 0.05 percent of that is 21.6 minutes. Useful anchors to have memorised: 99.9 percent is about 43 minutes a month, 99.95 is about 21.6, 99.99 is about 4.3, and 99.999 is about 26 seconds, which is less time than most on-call engineers take to open a laptop. That allowance motivates automatic mitigation; humans still design and operate the recovery mechanisms.
An error budget should change decisions. A possible policy pauses ordinary feature releases when the allowance is exhausted and prioritises the causes of user harm. Define exceptions for security fixes and recovery work, an owner who can approve them, and explicit recovery criteria. A freeze alone does not repair reliability; the team must test whether its corrective work reduces failures.
The second thing it changes is alerting. Alert on burn rate rather than on threshold breaches. A sustained 14.4x burn rate would exhaust a 30-day budget in 50 hours; one hour at that rate consumes 2 percent, and that deserves a page. A 1.5x burn over six hours is a ticket. This is what actually reduces alert fatigue, because it makes urgency proportional to consequence instead of paging on every transient blip.
The third is that it forces the SLI to be honest. Once a number gates releases, people stop choosing indicators that are easy to measure and start choosing indicators a user would recognise. A load-balancer SLI that counts HTTP5xx as failures can detect that outage correctly; one that checks only connections or response speed can miss it.
Request budgets need a defined denominator
For 10 million eligible requests and a 99.95 percent success objective, the allowance is 10,000,000 × 0.0005 = 5,000 bad requests. If 2,000 have failed, 40 percent of that allowance has been spent. This request-based calculation does not translate into 21.6 minutes unless traffic and the failure pattern justify that conversion. A short outage during a traffic peak can spend more than a longer quiet-period outage.
Define eligibility before publishing the number. Decide how to handle malformed client requests, authentication failures, timeouts and retries. If one failed user checkout generates three backend attempts, counting each attempt measures a different experience from counting the checkout once. Neither denominator should change silently during an incident.
Missing telemetry also needs an explicit state. A collector failure that removes both successes and failures must not make the service look perfect. Cross-check an independent traffic counter or external journey probe and mark the SLI uncertain when coverage is incomplete. Release decisions should record that uncertainty alongside remaining budget, the proposed change and its expected reliability effect.
What interviewers probe next
"Should you aim for 100 percent?" A measured 100 percent objective leaves no allowance for failures in its window. Choose an objective from user needs, consequences and achievable engineering measures; do not assume users cannot notice additional reliability. For critical operations, pair the objective with explicit safety and recovery requirements.
"Rolling window or calendar month?" State the policy. Rolling windows avoid a fixed reset boundary; calendar windows can align with contractual reporting. Use the agreed window consistently in budget calculations and explain how release decisions work near its boundaries.
"Who owns the SLO?" The team that owns the service, agreed with whoever is affected downstream. An SLO handed down by a platform team gets treated as someone else's number and stops influencing decisions.
Common mistakes
Hesitating on the arithmetic. Not having the figure to hand usually means the budget has never been used to decide anything.
Defining SLA as "a stricter SLO". The SLA is a contractual commitment; its relationship to the internal SLO must be stated, not assumed.
Describing an error budget with no consequence attached. If the answer ends at "we track it", the mechanism does not exist.
Picking an SLI that cannot go bad in the way users experience. Measuring uptime of the process rather than success of the request is the classic version.
References