Error budgets turn reliability from a vague aspiration into a planning tool. This guide explains how service-level indicators (SLIs), service-level objectives (SLOs), and burn rates work together, then provides a repeatable worksheet, calculation examples, and an error-budget policy you can use to make release and reliability decisions.
Overview
An error budget is the amount of unreliability a service can experience while still meeting its SLO. If a team sets a monthly availability SLO of 99.9%, the error budget is the remaining 0.1% of the agreed measurement window. The budget is not permission to create failures. It is a practical way to balance feature delivery with the reliability customers need.
Three concepts form the foundation:
- Service-level indicator (SLI): The measured signal, such as successful request ratio, latency, availability, or successful job completion.
- Service-level objective (SLO): The target for that signal over a defined window, such as “99.9% of valid API requests succeed over 30 days.”
- Service-level agreement (SLA): A customer-facing commitment that may include consequences or remedies. An SLO is an engineering target; an SLA is a broader business or contractual commitment.
For example, an availability SLO can use this formula:
Availability = successful valid events ÷ total valid events × 100
The corresponding error budget percentage is:
Error budget = 100% − SLO target
A team can then express the budget as events, minutes, or another unit that matches the SLI. Availability budgets are often translated into time, while request-based SLIs can be tracked as allowed failed requests. The important requirement is consistency: define which events count, how exclusions work, and which time window applies.
Error budgets are most useful when they influence decisions. A team might continue normal delivery while budget consumption is low, add reliability work as consumption accelerates, or pause risky changes when the budget is exhausted. This creates a shared operating model for engineering, product, and incident response rather than treating reliability as an informal preference.
How to estimate
Use the following sequence to design an SLO and estimate its budget.
- Choose a user-relevant outcome. Start with what customers experience: a page loads, an API returns a valid response, a message is processed, or a deployment completes successfully. Avoid choosing a metric only because it is easy to collect.
- Define the SLI event set. Specify valid requests, excluded traffic, regions, status codes, timeout treatment, and sampling rules. Write the definition so another engineer could implement it without guessing.
- Select the measurement window. A rolling window can support continuous operational decisions; a calendar window can align with planning and reporting. Either can work if the team understands when the budget resets or rolls forward.
- Set the SLO target. Choose a target that reflects user needs and the service’s role. Do not begin with maximum availability by default. A target should be observable, explainable, and achievable with the team’s current operating model.
- Convert the target into a budget. Subtract the SLO from 100%. For a 99.5% SLO, the budget is 0.5% of eligible events during the window.
- Define burn-rate responses. Burn rate compares the current rate of budget consumption with the rate that would consume the full budget evenly across the window. A burn rate of 1 means the budget is being consumed at the planned rate; a higher value indicates faster consumption.
For alerting, use at least two types of signals: a fast-burn alert for severe incidents and a slower-burn signal for sustained degradation. Exact thresholds should reflect the window, service criticality, traffic volume, and the cost of interruption. Avoid copying a threshold without testing whether it produces actionable alerts.
For related operational controls, connect the policy to your delivery workflow. A CI/CD pipeline design can expose deployment markers and rollback actions, while a Kubernetes deployment checklist can help verify health signals before and during rollout.
Inputs and assumptions
Complete this worksheet before publishing an SLO:
| Input | Worksheet question | Example assumption |
|---|---|---|
| Service | What user journey or component is covered? | Public checkout API |
| SLI | What counts as a good event? | Valid requests returning an acceptable response |
| Eligibility | Which events are included or excluded? | Exclude intentionally rejected requests; count timeouts as failures |
| SLO | What percentage of good events is required? | 99.5% over a rolling 30-day window |
| Budget | What is 100% minus the SLO? | 0.5% of eligible requests |
| Ownership | Who reviews consumption and approves exceptions? | Service owner with product and incident leads |
| Response | What happens at warning and exhaustion points? | Review risky releases; prioritize reliability when exhausted |
Document assumptions about planned maintenance, dependency failures, regional outages, synthetic checks, and low-traffic periods. Exclusions can be appropriate, but they should describe events outside the service’s control without hiding ordinary failure. When in doubt, record both the inclusive and excluded views so the team can see how much the definition changes the result.
Keep the SLO narrow enough to own and broad enough to represent the user experience. One service may need separate objectives for availability and latency. Combining unrelated signals into one score can conceal a serious problem in one dimension.
Worked examples
Example 1: Request-based availability
Assume a service records 2,000,000 eligible requests during a 30-day window. Its SLO is 99.5% successful requests.
- Allowed failure rate: 100% − 99.5% = 0.5%.
- Error budget in requests: 2,000,000 × 0.005 = 10,000 failed requests.
- If 4,000 failures have occurred, budget consumption is 4,000 ÷ 10,000 = 40%.
The team has not exceeded its budget, but the result is not automatically healthy. Check the trend, concentration, and cause. Four thousand isolated failures may require a different response from four thousand failures during a single deployment.
Example 2: Time-based availability
Suppose a service has a 99.9% availability SLO over a 30-day window. Using a 30-day planning approximation of 43,200 minutes:
- Allowed unavailability: 43,200 × 0.001 = 43.2 minutes.
- If measured unavailability reaches 50 minutes, the service has consumed more than the available budget for that approximation.
The exact result depends on the measurement window and the monitoring definition. Use the same calendar or rolling-window logic in dashboards, reports, and policy reviews.
Example 3: Burn-rate decision
If a service consumes 20% of its monthly budget in one hour, the immediate concern is the rate rather than only the percentage used. A continued incident at that pace could exhaust the remaining budget quickly. The response might be to stop a rollout, investigate a dependency, or invoke incident procedures. Once the rate returns to normal, the team can assess whether the underlying change deserves a permanent fix.
| Budget condition | Suggested delivery decision | Reliability action |
|---|---|---|
| Low consumption and stable trend | Continue planned work with normal review | Maintain monitoring and review causes of recent failures |
| Rising consumption or repeated fast burn | Limit risky changes and require additional rollout checks | Investigate, mitigate, and schedule corrective work |
| Budget exhausted | Pause nonessential risky releases until an exception is agreed | Prioritize remediation, incident learning, and validation |
| Persistent exhaustion across windows | Replan feature commitments that depend on reliability | Revisit architecture, capacity, dependencies, or the SLO definition |
This policy should not punish teams for honest reporting. The purpose is to make trade-offs visible and give teams authority to reduce risk. Link deployment ownership to your DevSecOps pipeline controls and document exceptions rather than bypassing the budget silently.
When to recalculate
Revisit the SLO and error-budget worksheet during quarterly planning, after a significant incident, before launching a new service, and whenever the user journey or architecture changes. Recalculate when traffic patterns, dependency boundaries, regions, deployment frequency, or observability instrumentation change. A metric that was representative before a migration may no longer describe the same service afterward.
Review the policy if alerts create repeated noise, fail to detect meaningful degradation, or trigger actions the team cannot complete. Check whether the SLI still reflects customer impact, whether exclusions remain defensible, and whether the response levels are clear enough for an on-call engineer to follow.
To put the approach into practice, choose one important service, write its SLI in plain language, calculate the budget from a stated window, and publish the decision table with named owners. Review the first reporting period with product and engineering together. Then adjust the definitions based on observed failure modes—not to make the numbers look better, but to make reliability decisions more useful.
Teams building supporting workflows can also consult the DevOps tools directory when selecting observability and delivery tools, and use the Git workflow guide to align release ownership with the team’s development process.
