SLI/SLO Calculator
Free web tool: SLI/SLO Calculator
Availability Target
99.9%
Allowed Downtime
Yearly
8h 45m 57s
Monthly
43m 50s
Weekly
10m 4s
Daily
1m 26s
Error Budget (Allowed Errors)
Yearly
365,250
Monthly
30,440
Daily
1,000
About SLI/SLO Calculator
The SLI/SLO Error Budget Calculator is a free tool for Site Reliability Engineers (SREs), DevOps teams, and platform engineers who need to quantify the practical consequences of an availability target. You select an availability level — 99%, 99.5%, 99.9% (three nines), 99.95%, 99.99% (four nines), or 99.999% (five nines) — enter your expected daily request volume, and the calculator immediately shows how much downtime you are allowed per year, month, week, and day, and how many errors are permitted per year, month, and day.
Service Level Indicators (SLIs), Service Level Objectives (SLOs), and error budgets are the foundation of the SRE practice pioneered by Google. An SLI is a quantitative measure of service reliability (such as request success rate or latency). An SLO is a target value for an SLI (such as 99.9% of requests succeed). The error budget is the amount of unreliability you are permitted — the difference between 100% and your SLO. It creates a business agreement between product teams (who want new features fast) and reliability teams (who want stability).
Technically, the calculator computes allowed downtime by multiplying (1 - availability) by the number of seconds in each time period: 365.25 days/year, 30.44 days/month, 7 days/week, and 1 day. The error budget is computed as (1 - availability) multiplied by the daily request count, scaled to each time period. Results use a human-readable duration format (days, hours, minutes, seconds) so you can immediately understand the real-world impact of your SLO target.
Key Features
- Six availability presets: 99%, 99.5%, 99.9% (three nines), 99.95%, 99.99% (four nines), 99.999% (five nines)
- Allowed downtime breakdown: yearly, monthly, weekly, and daily permitted outage duration
- Error budget breakdown: yearly, monthly, and daily allowed error counts based on your daily request volume
- Human-readable duration output in days, hours, minutes, and seconds
- Configurable daily request count for accurate error budget calculation per your traffic volume
- Real-time recalculation — results update instantly when you change the availability target or request count
- Clean side-by-side card layout for quick comparison of downtime vs. error budget at a glance
- 100% client-side calculation — no data is sent to any server
Frequently Asked Questions
What is an SLO and how does it differ from an SLA?
An SLO (Service Level Objective) is an internal target for service reliability, such as 99.9% of HTTP requests succeeding within 200ms. An SLA (Service Level Agreement) is a contractual promise to customers that includes penalties for violation. SLOs are stricter than SLAs — you typically set your SLO higher than your SLA so you have a buffer before breaching the contract.
What is an error budget and why is it useful?
The error budget is the allowed amount of unreliability within your SLO period. For a 99.9% SLO, the error budget is 0.1% of requests or time. It gives product teams a concrete "budget to spend" on risky deployments or features, and gives SRE teams a data-driven reason to slow down releases when the budget runs low — rather than arguing based on gut feeling.
What is the difference between three nines (99.9%) and four nines (99.99%)?
Three nines (99.9%) allows about 8.77 hours of downtime per year, or roughly 43.8 minutes per month. Four nines (99.99%) allows only 52.6 minutes per year, or about 4.38 minutes per month. Each additional nine reduces your allowed downtime by roughly 10x, requiring significantly more investment in reliability engineering to achieve.
How do I calculate my error budget in terms of number of errors?
Enter your average daily request count in the Daily Requests field. The calculator multiplies your daily requests by (1 - availability) to get the daily error budget, then scales it to monthly (x 30.44) and yearly (x 365.25). For example, with 1,000,000 daily requests and a 99.9% SLO, you are allowed 1,000 errors per day.
What counts as downtime when measuring against an SLO?
Downtime is any period when the service fails to meet the SLI threshold defined in the SLO. For a success-rate SLO, downtime is calculated as the fraction of failed requests multiplied by the measurement window. For a latency SLO, it is the fraction of requests that exceeded the latency threshold. Planned maintenance windows may be excluded depending on your SLA terms.
Is five nines (99.999%) achievable and what does it cost?
Five nines allows only about 5.26 minutes of downtime per year. Achieving it requires fully redundant infrastructure with no single point of failure, automated failover that completes in seconds, and rigorous change management to prevent human error. It is typically only cost-justified for critical financial, healthcare, or telecommunications services where downtime has severe consequences.
How should I use the error budget to make release decisions?
Track your real error rate against your SLO in a monitoring tool. When the error budget is healthy (above 50%), you can deploy frequently with confidence. When it drops below 10%, freeze non-critical deployments and focus on reliability work. When the budget is fully exhausted, stop all feature releases until reliability is restored. This policy turns reliability into a shared organizational goal.
What is the difference between SLI, SLO, and SLA?
SLI (Service Level Indicator) is the metric you measure, like request success rate. SLO (Service Level Objective) is your internal target for that metric, like 99.9% success rate. SLA (Service Level Agreement) is a contract with users or customers that typically includes consequences like refunds if the SLO is missed. The SLO should always be stricter than the SLA to prevent SLA breaches.