An error budget is the amount of unreliability a service can spend while still meeting its SLO. It turns reliability into an operating rule: when the budget is healthy, teams can ship; when the budget burns too fast, reliability work moves ahead of feature work.
For a 99.9% availability SLO, the error budget is 0.1% of the measurement window. That may mean 43.2 minutes of downtime in a 30-day month, 10,000 bad requests out of 10 million, or another unit that reflects the customer journey. The unit matters because the policy will later decide who pauses releases, who fixes defects, and who explains customer risk.
What an Error Budget Actually Measures
An error budget measures how many bad events, failed requests, minutes of downtime, or slow transactions a service can tolerate within a defined SLO window. It gives engineering and product teams a shared number for customer risk, rather than a debate based on incident volume or personal tolerance.
The basic formula is simple: error budget equals 100% minus the SLO target. Allowed bad events equal total valid events multiplied by the allowed failure rate. Remaining budget equals allowed bad events minus consumed bad events. For time-based availability, allowed downtime equals the SLO window length multiplied by the allowed failure rate.
Example:
- SLO target: 99.9% availability
- SLO window: 30 days
- Error budget: 0.1%
- Allowed downtime: 30 x 24 x 60 x 0.001 = 43.2 minutes
For request-based reliability:
- Total valid requests in the window: 8,000,000
- SLO target: 99.9%
- Error budget: 0.1%
- Allowed bad requests: 8,000,000 x 0.001 = 8,000 bad requests
Request-based budgets are often better for APIs, checkout flows, login, search, and other services where traffic volume changes during the day. Time-based budgets are easier to explain to executives, but they can hide short, severe incidents during peak traffic.
Google's SRE workbook describes the same basic relationship: an SLO target leaves an error budget equal to the remaining allowed miss rate. Google Cloud's service monitoring guide also frames the budget as eligible events multiplied by the allowed failure rate, which is why event definitions matter.
Define a bad event before you calculate anything. A failed request may be a 5xx response, a timeout, a wrong response, or a successful response that took longer than the latency threshold. If the SLI definition is vague, the error budget will create more argument than discipline.
SLO, SLI, SLA, and Error Budget: The Decision Table
SLOs, SLIs, SLAs, and error budgets answer different questions. The SLI is the measurement, the SLO is the internal target, the error budget is the allowed miss rate, and the SLA is the customer-facing commitment with commercial or legal consequences.
| Term | What it means | Decision it supports | Example | Watch out |
|---|---|---|---|---|
| SLI | A measured reliability signal | Whether users received a good or bad experience | 99.95% of checkout requests completed under 800 ms | Vendor uptime alone may miss user-facing failures |
| SLO | An internal reliability target for a service or journey | Whether teams can keep shipping or must reduce risk | Checkout availability must be 99.9% over 30 days | Copying a target from another company creates false precision |
| Error budget | The allowed amount of SLO miss | How much failure the team can tolerate before changing priorities | 0.1% bad checkout requests per 30 days | A budget without response rules becomes a dashboard metric only |
| SLA | A contract or customer promise | What the company owes if service commitments are missed | Enterprise customers receive credits below 99.5% monthly uptime | Legal promises must be backed by measurable service data |
Use SLAs sparingly and write them with evidence from real service behavior. A product can have a strict internal SLO without offering the same target in a contract. That gap gives engineering room to protect customers before the business owes credits or escalations.
A useful pattern is to set the SLO tighter than the SLA. If the SLA promises 99.5% monthly availability, an internal SLO of 99.9% gives teams time to respond before customer penalties appear.
How to Build an Error Budget Policy
An error budget policy turns the budget into agreed behavior before the next incident. It should define who owns each service, which events count against the budget, which window is used, when releases pause, and how product, engineering, and support review exceptions.
Start with the services that carry revenue, safety, compliance, or retention risk. Most organizations do not need SLOs for every background job on day one. Start with login, payment, onboarding, messaging, search, data sync, reporting, and customer-facing APIs.
A practical policy should answer six questions.
- Who owns the service? Name one accountable owner and one backup.
- What is the SLO window? Use a rolling 28- or 30-day window for operational control. Use calendar windows when customers or finance teams require monthly reporting.
- Which events consume the budget? Count only events that match the SLI definition and affect the user journey.
- What happens at each budget state? Define actions before pressure rises.
- How does the policy affect releases? Put budget checks into planning, release approval, and CI/CD gates.
- How often is the policy reviewed? Review weekly during rollout, then monthly once teams trust the data.
| Policy area | Decision | Owner | Failure mode |
|---|---|---|---|
| Service ownership | Name one service owner and escalation backup | Engineering manager or platform lead | No one can approve a release pause |
| SLO window | Choose rolling, calendar, or both | Platform team and product owner | Teams argue over reporting periods |
| Eligible events | Define bad requests, latency misses, timeouts, data loss, and exclusions | Service owner, QA, support | Dashboards disagree with customer tickets |
| Budget thresholds | Set healthy, watch, at-risk, and exhausted states | SRE/DevOps lead with product owner | Every incident triggers a different reaction |
| Release gates | Decide when feature releases pause or need approval | Release manager | CI/CD keeps shipping into a known failure pattern |
| Exception process | Define who can approve security fixes, contractual work, and urgent patches | CTO or delegated product leader | Every feature becomes an exception |
| Review cadence | Review budget, top causes, and policy changes | Product and engineering pair | The policy decays after launch |
A simple response model works well:
- 0-50% budget consumed: normal delivery, with routine monitoring.
- 50-75% consumed: review risky changes, inspect recent incidents, pull one reliability item into the sprint.
- 75-100% consumed: require release owner approval for non-urgent changes, fix the largest budget consumers.
- Over 100% consumed: pause non-essential feature releases, run an incident review, and resume only when owners agree on corrective work.
Put the release gate where teams already work. If the delivery process is weak, start with DevOps pipeline optimization before adding more rules. For teams formalizing deployment flow, connect the policy to continuous integration and continuous delivery so budget state can inform release approval without manual chasing.
Use Burn Rate Alerts Before the Budget Is Gone
Burn rate alerts detect when a service is consuming its budget faster than the SLO window can tolerate. They are more useful than raw error-rate alerts because they connect severity to the remaining reliability budget, the length of the window, and the response needed from the team.
Use a simple formula: burn rate equals observed error rate divided by allowed error rate.
For a 99.9% SLO, the allowed error rate is 0.1%. If the current error rate is 1%, the burn rate is 10x. If that rate continues, a 30-day budget can disappear in about three days.
Google's burn-rate alerting guidance uses the same idea: the alert should warn teams before the SLO runs out of budget, not merely after a user-facing failure has become obvious.
Good alerting separates fast burns from slow burns:
- Fast burn: a severe issue is consuming budget quickly. Page the on-call engineer.
- Medium burn: the issue may not be a full outage, but it threatens the monthly target. Route to the service team during working hours.
- Slow burn: reliability is drifting. Add it to sprint planning and budget review.
Use multiple windows to avoid noise. A five-minute spike can be useful for paging if it also appears in a longer window. A one-hour or six-hour window helps catch issues that are too slow for outage alarms but too expensive to ignore.
Avoid these alerting mistakes:
- Alerting on CPU, memory, or queue depth as if they were customer-facing SLOs.
- Paging on every small SLI movement.
- Using one alert route for all services.
- Creating burn-rate alerts from different data than the SLO dashboard.
- Ignoring missing telemetry, which can make reliability look better than it is.
Burn-rate alerts need runbooks. The first action should be clear: roll back, disable a feature flag, scale a dependency, fail over, notify support, or open an incident. If the alert only says "SLO burn high," the on-call team still has to diagnose the operating rule under stress.
Make Error Budgets Useful for Product and Engineering Decisions
Error budgets work when they are tied to planning, release approval, incident review, and roadmap tradeoffs. Product leaders get a clear view of customer risk; engineering leaders get permission to fix weak systems when budget loss proves that reliability debt is hurting delivery.
Use the budget review as a planning meeting, not a reporting ritual. Keep it short and focused:
- Budget remaining by customer journey.
- Largest budget consumers in the last week.
- Incidents that should change the SLO, SLI, or policy.
- Releases planned for the next seven days.
- Reliability work that must move ahead of feature work.
- Customer or SLA exposure that needs executive attention.
The decisions should be concrete. If a payment service consumed 70% of its monthly budget because a provider timed out, do not approve an optional UI release until retry behavior, fallback routing, and provider observability are addressed. If login has used only 10% of its budget and the next release is low risk, ship.
This is where product operations matter. In a Jira-like CRM/ERP project, backlog and sprint management, planned-versus-actual analytics, reporting, Slack notifications, and email notifications gave teams workflow visibility during a 9-month delivery with a $50,000-$100,000 budget band. Reliability work needs the same visibility: owner, sprint, status, impact, and decision history.
Complex products also need platform-level discipline. In the RAE Health healthcare product, wearable, mobile app, and web portal integration ran over 24+ months in a $200,000+ budget band. The backend and architecture included AWS, ECS, RDS, Cognito, SQS, Jenkins, Terraform, Grafana, Semgrep, Docker scan, Trivy, and Dojo. Systems like that cannot rely on release intuition. They need SLO dashboards, security checks, deployment gates, and incident feedback loops.
For product leaders, error budgets create a fair way to discuss tradeoffs. Feature delay becomes a risk decision, not an engineering preference. For engineering leaders, reliability work gets tied to customer outcomes, not internal cleanup language.
Need reliability targets your teams can actually run?
We can turn incidents, release goals, and customer commitments into SLOs, dashboards, and DevOps gates.
When to Ask for DevOps and Reliability Help
Bring in DevOps and reliability help when SLOs are unclear, incidents repeat, dashboards do not match customer pain, or release teams cannot agree when to pause feature work. Outside facilitation is useful when product commitments, infrastructure limits, and support signals need one operating model.
You may need help if:
- SLAs are being negotiated without service-level data.
- Uptime looks fine while customers report failed workflows.
- Incidents repeat after every large release.
- CI/CD does not check reliability state before deployment.
- Support tickets, logs, metrics, and traces tell different stories.
- Teams cannot agree whether a failure should consume the budget.
- Reliability work never survives sprint planning.
Attract Group can help define SLOs, SLIs, error budget policies, dashboards, alert routes, and release gates through DevOps & Cloud. If your current product needs continuous monitoring, fixes, and operational ownership, Maintenance & Support may be the better starting point. For deeper product rebuilds or new platforms, reliability targets should be part of Custom Software Development from the first architecture decisions.
FAQ
Use the FAQ as a quick decision check before you write the policy. The answers below keep the language precise enough for executives, product managers, and engineering teams to discuss budget consumption, SLO targets, and customer commitments without turning the topic into an SRE-only document.
What is an error budget in simple terms?
An error budget is the amount of failure a service can have while still meeting its SLO. If the SLO is 99.9%, the budget is the remaining 0.1% of bad requests, failed minutes, or another measured unit.
What is the difference between SLI, SLO, SLA, and error budget?
An SLI is the measurement. An SLO is the internal target. An SLA is the customer-facing commitment. The error budget is the amount of SLO miss allowed before teams change release, incident, or reliability priorities.
What happens when an error budget is exhausted?
The policy should define the response. Common actions include pausing non-essential releases, fixing the largest budget consumers, running an incident review, tightening monitoring, and requiring product or engineering approval before new changes ship.
