An SLO needs a measurement to be judged against, and for availability that measurement usually comes from outside your infrastructure. Hyperping records every check on every monitor and reports uptime, outages, and total downtime for any period, which gives you the SLI to compare with the objective. The same data is available from the Reports API if you track several SLOs in your own dashboard.
Parts of an SLO
A usable SLO names three things:
- The indicator (SLI): what you measure. For example, the share of HTTP checks on the checkout API that return a 2xx in under 1 second.
- The target: the threshold, such as 99.95%.
- The window: the period it is measured over. A rolling 30 days is the most common choice, because a calendar month resets the score on the 1st and hides a bad last week.
Put together: "99.95% of checks on the checkout API succeed in under 1 second, over a rolling 30-day window."
SLO vs SLA
An SLA is a contract with customers and money attached. An SLO is the target your team works toward. Keep the SLO tighter than the SLA (99.95% internally for a 99.9% SLA, for example) so you see the trend and fix it before a breach costs credits. Some teams have SLOs and no SLA at all, which is fine: the SLO still tells you when reliability needs attention.
SLOs and error budgets
The gap between 100% and the SLO is the error budget. A 99.95% SLO over 30 days allows about 21 minutes of failure. While most of the budget is left, the team ships features at its normal pace. When it's nearly gone, reliability work moves ahead of new features until the window recovers. That rule is what turns an SLO from a number on a dashboard into a decision.
How to pick an SLO
- Start from what you measure today. If the last three months were at 99.97%, a 99.95% SLO is realistic, and 99.99% would be a promise you can't keep.
- Write SLOs for what users do, not for each server. One SLO on "users can log in" beats five on the machines behind it.
- Keep the number small. Three to five SLOs per product is enough to act on.
- Review them every quarter. An SLO that is never close to breached is probably too loose to drive any decision.
FAQ
What is a good SLO?
For a customer-facing web service, 99.9% to 99.95% availability over 30 days. Pick a value you already meet most months, then tighten it once the team is used to working with an error budget.
What is the difference between an SLI and an SLO?
The SLI is the measured value, such as 99.97% of checks passing this month. The SLO is the target that value is compared with, such as 99.95%.
Can an SLO be 100%?
No. A 100% SLO leaves no error budget, so every deploy, network blip, and dependency failure counts as a miss, and the team stops shipping. Users also can't tell the difference between 99.99% and 100% through their own network.