Calculate your SRE error budget from SLO targets. Convert reliability objectives into allowed downtime minutes per month, quarter, and year.
An error budget is the maximum amount of unreliability your service can tolerate while still meeting its Service Level Objective (SLO). Pioneered by Google's SRE team, error budgets transform abstract reliability targets into concrete, spendable quantities of allowed downtime or errors.
This calculator converts your SLO percentage into the allowed error budget across multiple time periods — per year, quarter, month, week, and day. For example, a 99.9% SLO gives you 43.8 minutes of allowed downtime per month. You can "spend" this budget on deployments, experiments, or planned maintenance.
Error budgets create alignment between development velocity and reliability. When the budget is healthy, teams can ship faster and take risks. When the budget is depleted, the team must focus on reliability improvements. This calculator helps SRE teams, product managers, and engineering leaders quantify and manage that balance.
This measurement provides a critical foundation for capacity planning and performance budgeting, helping teams align infrastructure resources with application requirements and growth projections.
Error budgets provide a data-driven framework for balancing reliability with feature velocity. Without an error budget, teams argue subjectively about when to slow down deployments. This calculator gives you the exact numbers — how many minutes of downtime remain this month, enabling objective decision-making about risk and release cadence. Regular monitoring of this value helps DevOps teams detect anomalies early and maintain the system reliability and performance that users and business stakeholders expect.
Error Budget = (1 − SLO/100) × Period. For a 99.9% SLO over 30 days: budget = (1 − 0.999) × 30 × 24 × 60 = 43.2 minutes.
Result: 21.6 minutes/month
With a 99.95% SLO, the error budget is 0.05% of total time. Over a 30-day month (43,200 minutes), this equals 21.6 minutes of allowed downtime. Per year, the total error budget is 4.38 hours.
Error budgets were popularized by Google's SRE book. The core insight is that 100% reliability is neither achievable nor desirable — pursuing it would halt all innovation. Instead, teams define an acceptable level of unreliability (the error budget) and use it as a resource.
An error budget policy defines actions triggered by budget status. When budget is healthy (>50% remaining), teams can deploy freely. When depleted, feature releases pause and the team focuses on reliability. This removes subjective arguments about when to slow down.
Sophisticated teams track error budgets over multiple windows simultaneously — a 30-day rolling window for recent trends and a 90-day window for long-term health. This prevents gaming where a team burns the budget early in the month.
Error budgets can be expressed in business terms: revenue at risk, user sessions affected, or support tickets generated. This helps non-technical stakeholders understand reliability trade-offs in terms they care about.
An error budget is the allowed amount of unreliability for a service, calculated as 1 minus the SLO. It represents the total downtime or errors your service can experience while still meeting its reliability target over a given period.
An SLA is a contractual commitment with financial penalties. An SLO is an internal target, typically stricter than the SLA. The error budget is derived from the SLO, not the SLA. You use the error budget for internal decision-making about risk.
When the error budget is depleted, teams should freeze non-critical deployments and focus on reliability improvements. This is defined in an error budget policy. The exact response varies — some teams halt all changes, others only halt risky ones.
Yes. Error budgets work for any SLI. For latency, you might define an SLO that 99.9% of requests complete within 200ms. The error budget is the allowed 0.1% of requests that can exceed that threshold.
Use monitoring tools like Prometheus, Datadog, or Google Cloud SLO monitoring to track SLI compliance over rolling windows. Calculate the remaining budget as the target minus actual error rate, multiplied by the period.
Error budgets are most valuable for user-facing services with clear reliability expectations. Internal batch jobs or development environments may not need formal error budgets. Focus on services where reliability directly impacts users or revenue.