About the SLO / SLI Calculator
The number that changes behaviour is not the SLO, it is the error budget it implies. Three nines sounds strict until you convert it: 99.9% availability allows about 43 minutes of downtime a month, and 99.99% allows about four. That conversion is what makes a target concrete enough to argue about.
The common mistake is setting a target by picking the most nines that sound impressive. Every additional nine multiplies cost — in redundancy, in on-call load, in the engineering time spent defending it — and the difference is rarely visible to users whose network is less reliable than your service. Pick the target from what users actually notice, then check the budget it produces is one you can live with.
The SLI matters more than the SLO. A target measured against the wrong indicator is precise and meaningless: availability measured at a load balancer that is up while the application returns errors will report a healthy service during an outage. Measure as close to the user's experience as you can.
Frequently asked questions
What is an error budget and how do I use it?
It is the amount of unreliability your SLO permits — the inverse of the target over a window. At 99.9% over 30 days that is roughly 43 minutes. Its value is as a decision rule: budget remaining means you can take deployment risk, budget exhausted means reliability work takes priority over features. Without that agreement in advance, the number is just reporting.
How many nines should I target?
Fewer than instinct suggests. Start from what users would actually notice and complain about, not from what sounds rigorous. Each nine multiplies cost in redundancy and on-call burden, and beyond a point the user's own network is less reliable than your service, so the improvement is invisible to them. Most internal services are well served by 99.9%.
Should the window be rolling or calendar-based?
Rolling, for operational decisions. A calendar month resets the budget at midnight on the first, which means an incident on the 31st is forgiven the next day and the team learns nothing. A rolling 30-day window keeps recent failures visible for the full period, which is what makes the budget behave like a real constraint.
What is the difference between an SLI, an SLO and an SLA?
The SLI is the measurement — the proportion of requests that succeeded. The SLO is your internal target for that measurement. The SLA is a contract with financial consequences. Set the SLO meaningfully stricter than any SLA, so you detect and respond to a problem well before it becomes a commercial one.
Should availability be measured by time or by requests?
Request-based is usually closer to user experience. Time-based availability treats a minute where one request in a thousand failed the same as a minute where everything failed. Counting good requests against total requests reflects how many users were actually affected, which is what the budget is meant to represent.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.