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.
The part that matters. An error budget is only real if spending it changes a decision. The policy I would write: while the budget is intact, teams ship freely, and reliability work competes with features on its merits. When the budget is exhausted, feature releases stop and the next work item is whatever caused the burn. Not a meeting, not a retrospective action, an actual freeze that lifts when the trailing window recovers. If nothing stops when the budget is gone, you do not have an error budget, you have a dashboard.
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.
What interviewers probe next
"Should you aim for 100 percent?" No, and refusing is the point. The cost curve is superlinear and the user cannot tell the difference above a level set by their own network. An SLO below 100 percent is a deliberate budget for change.
"Rolling window or calendar month?" Rolling, typically 28 days. A calendar month resets the budget on the first, which quietly encourages shipping risk late in the month and creates a cliff nobody chose.
"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. Interviewers read the pause correctly.
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