SLO page#
A service level objective states the reliability you intend to deliver, as a number, over a window. The SLO page tracks how you are doing against it.
What an SLO is#
Three parts:
- Indicator: what is measured, for example the proportion of successful checks against a service.
- Objective: the target, for example 99.9 percent.
- Window: the period, for example rolling 30 days.
The gap between the objective and 100 percent is the error budget. At 99.9 percent over 30 days, the budget is about 43 minutes of downtime. Spending it is not failure; it is what the budget is for. Spending it all in the first week is the signal.
Prerequisites#
SLOs are calculated from monitor results, so create the monitors first.
- Monitors → Create monitor.
- Choose the check type: HTTP, SSL, DNS, TCP or ping.
- Set the target, the interval, and how many consecutive failures count as down.
Point the check at what your users actually use. A check against a health endpoint that returns OK while the application is failing will report excellent availability during an outage.
Add a second check that exercises a real read path touching the database. Together they distinguish "the web tier is up" from "the system works", which is usually the distinction that matters during an incident.
Creating an SLO#
SLO → Create SLO:
- Name it after the user-facing thing, for example "Checkout availability", not after a host.
- Select the monitors that make up the indicator.
- Set the objective, for example 99.9.
- Choose the window: rolling 7, 30 or 90 days.
Reading the page#
Current attainment against target for the window. Error budget remaining, as a percentage and as time. Burn history, showing when budget was consumed, which lines up with your incidents. Contributing outages, listed with duration and cause.
The important number is the budget remaining, not the attainment percentage. Attainment of 99.92 percent against a 99.9 target sounds comfortable; the same figure with the whole month still to run does not.
Choosing a target#
Pick something you can actually meet, and that reflects what the business needs.
| Target | Downtime per 30 days | Reasonable for |
|---|---|---|
| 99.0% | 7h 18m | Internal tools |
| 99.5% | 3h 39m | Non-critical services |
| 99.9% | 43m | Most production services |
| 99.95% | 21m | Revenue-generating paths |
| 99.99% | 4m | Systems with redundancy designed for it |
A target of 99.99 percent means four minutes a month, which is less than most deployments take. Committing to it without the architecture to support it turns the SLO into a number nobody trusts.
Alerting on error budget#
Alert on the budget, not only on the outage. A rule that fires when more than half the budget is consumed with more than half the window remaining catches slow degradation that never triggers a downtime alert.
Status pages#
An SLO's underlying monitors can also drive a public or private status page under Status pages. Group components as your customers understand them rather than by internal architecture, because that page is read by people who do not know how the system is built.