SLA / Error Budget Calculator
Calculate your error budget, track remaining downtime, and understand what each SLA level means.
Configuration
What is an SLA Calculator?
A Service Level Agreement (SLA) defines the expected uptime for a service, typically expressed as a percentage like 99.9% (three nines) or 99.99% (four nines). Each additional nine dramatically reduces allowed downtime—99.9% allows about 43 minutes of downtime per month, while 99.99% allows only about 4 minutes. An error budget is the inverse of the SLA: it represents the acceptable amount of unreliability, giving engineering teams a quantitative framework for balancing reliability with velocity.
SRE teams, DevOps engineers, and engineering managers use this calculator to understand the real-world implications of their SLA commitments, track remaining error budget during the current period, and make informed decisions about whether to push risky deployments or focus on reliability improvements. The error budget concept, popularized by Google's SRE practices, enables data-driven conversations between product and engineering teams about the acceptable pace of change versus stability requirements.
Frequently Asked Questions
How much downtime is allowed for 99.9% SLA?
A 99.9% SLA allows approximately 43 minutes and 50 seconds of downtime per month, 8 hours and 45 minutes per year. This is the most common SLA level for business-critical internal services. For customer-facing services that generate revenue, 99.95% or 99.99% is more typical, allowing only 21 minutes or 4 minutes per month respectively.
What is an error budget?
An error budget is the maximum amount of unreliability your service can have before violating its SLA. If your SLA is 99.9%, your error budget is 0.1% of total time. When error budget is available, teams can deploy faster and take more risks. When budget is running low, teams should slow down deployments and prioritize reliability work. It provides an objective threshold for the reliability vs. velocity tradeoff.
What happens when error budget is exhausted?
When the error budget is fully consumed, teams typically implement a deployment freeze (no non-critical changes), shift engineering effort to reliability improvements (fixing flaky tests, improving monitoring, adding redundancy), and conduct a review of recent incidents that consumed the budget. The specific response should be defined in advance through an error budget policy agreed upon by engineering and product leadership.