Error Budgets
An error budget is the amount of unreliable service behavior allowed by a service level objective during a defined period. Teams use it to make shared, data-based decisions about release risk and reliability work.
itPlatform engineering and SRE | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Error Budgets
An error budget is the portion of an SLO that permits imperfect service. It is not an allowance for careless outages. It is a way to stop reliability and feature delivery arguing by instinct when a number can carry the argument instead. The spreadsheet has brought a ruler to the emergency. This is unusually helpful.
Everything hangs from the service level indicator, or SLI: a measure of a user journey. For a request service, that can be good requests divided by eligible requests. The word “eligible” is doing more work than it appears to be doing. It decides which requests count, which do not, and whether the resulting number describes users or merely describes a convenient data source.
The service level objective, or SLO, states the target for that indicator over a window. The budget is the complement. A 99.9 percent target leaves 0.1 percent for bad events. This does not mean a service must use the allowance, like a holiday nobody wanted but HR insisted existed. It means that a release decision has a shared boundary when failures occur.
The next useful figure is burn rate, the speed at which current errors consume that allowance. Remaining budget says how much room is left. Burn rate says whether the room is disappearing at a pace that deserves a page, a ticket, or a careful look at the dashboard before somebody presses a deploy button with great confidence and poor timing.
The surprising part is that the arithmetic is the least troublesome piece. A precise budget can still be wrong if the SLI misses the journey users care about, if a global total hides one damaged region, or if a low-traffic service turns one failed request into a dramatic short-window rate. The number needs its window, population, data source, and segmentation attached. Without those, it is a percentage wearing a tie.
An error budget policy is what makes the measurement consequential. It names the actions near exhaustion, the exceptions for urgent security or reliability work, the people who can decide, and the route for disagreement. Without it, the budget can measure trouble very accurately while nobody has authority to change the plan.
Read the Intro for the full control loop and the choices behind an SLI and SLO. Use the Slides when the relationship between window, budget, burn rate, and policy needs to fit in one glance. Keep the Cheatsheet nearby for the formulas and diagnostic signals. The Quiz checks the distinctions that tend to tangle. The practice exercise then turns a fictional API’s measurements into a release decision, which is where this idea stops being a decorative decimal.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://sre.google/sre-book/service-level-objectives/
Supports
- Definitions and distinctions for SLI, SLO, and SLA
- User-centered indicator selection and limits of aggregate measurement
- SLO violation rate as an input to release decisions
- Quiz question 7 and the first reference-link rationale
- https://sre.google/sre-book/embracing-risk/
Supports
- Error budgets as objective measures of permitted unreliability
- Alignment of product velocity and reliability incentives
- Release continuation while budget remains and reliability action after exhaustion
- Quiz question 1 and the second reference-link rationale
- https://sre.google/workbook/implementing-slos/
Supports
- Good events divided by total events as an SLI pattern
- Error budget as one hundred percent minus the SLO
- Event-based budget calculation and incident budget consumption
- Rolling and calendar-aligned window tradeoffs
- Four-week rolling window, weekly summaries, and quarterly reports as a general starting approach
- Stakeholder agreement, policy contents, dashboards, reports, continuous review, and decision making
- Quiz questions 1, 6, 7, 9, and 10 and the third reference-link rationale
- https://sre.google/workbook/error-budget-policy/
Supports
- Policy goals, non-goals, change controls, reliability actions, exceptions, and escalation
- A 99.9 percent SLO producing a 0.1 percent budget and one thousand errors per million requests
- Policy as protection rather than punishment
- Quiz questions 2, 3, and 6 and the fourth reference-link rationale
- https://sre.google/workbook/alerting-on-slos/
Supports
- Burn-rate definition and interpretation
- Multiple burn rates for urgency-aware paging and ticketing
- Multiwindow alerting using long and short windows
- Low-traffic denominator problems
- Quiz questions 4, 5, 8, and 10 and the fifth reference-link rationale
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the Awesome Site Reliability Engineering list
- https://github.com/dastergon/awesome-sre
Supports
- Discovery of the Awesome SRE Tools list
- SRE ecosystem relevance of SLO monitoring and alerting resources
- https://github.com/SquadcastHub/awesome-sre-tools
Supports
- Discovery of Prometheus, Grafana, and SLO Exporter as SRE ecosystem tools
- https://prometheus.io/docs/introduction/overview/
Supports
- Prometheus time-series collection, querying, recording rules, and alerting
- Prometheus Awesome Links rationale
- https://grafana.com/docs/grafana/latest/
Supports
- Grafana dashboards, data-source queries, transformations, annotations, and alerting
- Grafana Awesome Links rationale
- https://github.com/seznam/slo-exporter
Supports
- Event processing into standardized SLI and SLO metrics
- Included examples, Grafana dashboards, Prometheus recording rules, and alerts
- SLO Exporter Awesome Links rationale
- https://docs.nobl9.com/guides/slo-guides/slo-calculations/
Supports
- Nobl9 occurrence and time-slice error-budget calculation methods
- Nobl9 Landscape placement
- https://docs.datadoghq.com/service_level_objectives/error_budget/
Supports
- Datadog error-budget alert thresholds for metric, monitor, and time-slice SLOs
- Datadog Landscape placement
- https://grafana.com/docs/grafana-cloud/alerting-and-irm/slo/create/
Supports
- Grafana SLO ratio queries, automatic error-budget calculation, recording rules, dashboards, and burn-rate alerts
- Grafana Cloud Landscape placement
- https://docs.newrelic.com/docs/service-level-management/alerts-slm/
Supports
- New Relic error-budget consumption and fast- and slow-burn alert conditions
- New Relic Landscape placement
- https://docs.dynatrace.com/docs/deliver/service-level-objectives
Supports
- Dynatrace DQL SLO definitions and per-entity error-budget burn-rate calculation
- Dynatrace Landscape placement
