Reliability as a budget
Translate a user promise into a measurable objective and use the remaining room for failure to guide decisions.
BY THE END, YOU CAN
- Define an SLI with a precise numerator and denominator
- Calculate a request-based error budget
- Distinguish budget burn from raw error rate
Diagram description: Days elapsed: 12 of 30; Budget used: 72 of 100
Define good service in user terms
A service-level indicator is a measurement; a service-level objective is a target for that measurement over a window.
For Relay, one indicator might be the proportion of eligible accepted jobs completed within sixty seconds. Define eligible, accepted, completed, and the measurement window precisely. Decide how cancelled jobs, invalid jobs, and jobs still in flight are counted.
A vague availability percentage can reward the wrong behavior if the endpoint responds successfully while jobs never finish. Measure the outcome the user actually depends on.
Calculate the allowed failure
For a request-based objective of 99.9% good events, the allowed bad-event fraction is 0.1%.
Across 100,000 eligible events, the budget is 100 bad events. This is an event budget, not automatically a number of downtime minutes; a time-based indicator uses a different denominator. The budget is a decision tool: enough remaining room may support a cautious release, while rapid consumption calls for reliability work or mitigation.
It is not permission to intentionally fail users or a promise that every user receives identical service.
Watch how quickly the budget burns
Burn rate compares the observed bad-event fraction with the allowed fraction.
If the allowed fraction is 0.1% and the observed fraction is 1%, the burn rate is ten times the sustainable rate for that objective. Short windows detect sharp incidents, while longer windows reduce noise and reveal sustained harm. Low traffic needs special care because one event can dominate a ratio.
Alerting should combine urgency, impact, and actionable thresholds rather than paging for every deviation. Revisit objectives when user needs or system behavior change.
COMMON FAILURE MODE
Removing failed or slow jobs from the denominator improves the metric while hiding user harm. Define eligibility before looking at outcomes.
TRY IT YOURSELF
For 200,000 eligible jobs and a 99.5% objective, calculate the bad-job budget. If 400 jobs are already bad, calculate how many remain in the budget.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Write one Relay SLO with an exact counting rule, window, target, and response policy for rapid budget consumption.