SLA & Uptime Calculator
Calculate allowed downtime across different time windows based on your availability targets, and track your error budget burn rate. Everything runs entirely in your browser.
SLA Downtime Calculator
Calculate allowed downtime based on your availability target across standard time horizons.
Error Budget Burn Rate
Determine how quickly your service consumes its allowed error budget.
Assumes full budget is available at the start of the window.
Common Nines Reference
Standard availability targets and their corresponding downtime allowances (computed using 365.25 days per year).
| Availability | Downtime/Year | Downtime/Month (avg) | Downtime/Week |
|---|---|---|---|
| 99%(two nines) | 3d 15h 39m 36s | 7h 18m 18s | 1h 40m 48s |
| 99.5% | 1d 19h 49m 48s | 3h 39m 9s | 50m 24s |
| 99.9%(three nines) | 8h 45m 58s | 43m 50s | 10m 5s |
| 99.95% | 4h 22m 59s | 21m 55s | 5m 2.4s |
| 99.99%(four nines) | 52m 36s | 4m 23s | 1m 0.5s |
| 99.999%(five nines) | 5m 15.6s | 26.3s | 6.0s |
Understanding SLAs, SLOs, and Error Budgets
In modern Site Reliability Engineering (SRE), balancing release momentum with system stability relies on clear availability boundaries. Three related concepts define this discipline: Service Level Agreements (SLAs), Service Level Objectives (SLOs), and Service Level Indicators (SLIs).
An SLI (Service Level Indicator) tracks an operational metric in real time, such as the fraction of HTTP requests returning successful status codes or p99 database response latency. An SLO (Service Level Objective) sets the internal reliability threshold your engineering team aims to maintain, providing an agreed error budget for deployments and upgrades. An SLA (Service Level Agreement) is the formal business commitment made to customers, specifying billing credits or contract remedies when uptime falls below external promises.
A common industry pitfall is treating internal SLOs and external SLAs as interchangeable. Because violating an SLA carries financial and contractual penalties, engineering teams intentionally target stricter internal SLOs than their public customer contracts require, ensuring safety margin before legal commitments trigger.
Worked Example: The Three Nines
Committing to a 99.9% uptime target (commonly termed “three nines”) allocates an error budget of 0.1%. Across an average calendar month of 30.44 days (365.25 days / 12), this permits about 43 minutes and 50 seconds of cumulative downtime. Over a strict 30-day window, the budget shrinks slightly to 43 minutes and 12 seconds. A single deployment outage lasting 45 minutes consumes the entire month's error allowance.
In DevOps and SRE interviews, interviewers frequently probe how error budgets influence production velocity. A burn rate exceeding 1.0x signals that observed errors will consume the total budget before the measurement window concludes. Freezing feature releases is an organizational policy decision rather than an automatic mandate; teams typically reserve deployment pauses for severe burn spikes or complete budget exhaustion, while ensuring ongoing visibility into time to exhaustion.