What is an SLO?
An SLO (service level objective) is an internal target for a service level indicator over a time window, for example 99.9% of requests succeed over a rolling 28 days. It defines how reliable the service needs to be, and the gap between 100% and the SLO is the error budget that teams can spend on change.
Why an SLO matters
Without an SLO, reliability is either ignored until customers complain or chased towards 100%, which no system reaches and which slows every release. An explicit target says when reliability is good enough and when it needs attention.
SLOs also make alerting saner: page when the error budget is burning fast, not whenever a single metric crosses a line.
How to measure an SLO
allowed bad events = (1 − SLO) × valid events in the window budget remaining = allowed bad events − bad events so far
Worked example
An API has an SLO of 99.9% over 28 days and serves about 12,000,000 requests in that window. Halfway through, 7,800 requests have failed.
- Allowed failures = 0.001 × 12,000,000 = 12,000.
- Remaining = 12,000 − 7,800 = 4,200, which is 35% of the budget.
- 65% of the budget is gone after 50% of the window.
Result: At this pace the SLO will be missed before the window ends, so the team should slow risky releases and look at what caused the failures.
Common mistakes
- Aiming for 100%. It cannot be achieved, and each extra nine costs far more than the last.
- Too many SLOs. A few that reflect user journeys beat dozens nobody reads.
- Setting the SLO from aspiration. Start from what you achieve now and what users need, then tighten.
- No consequence. An SLO that changes no decision when it is missed is decoration. Pair it with an error budget policy.
How Vigil handles an SLO
- Vigil lets you set an SLO target per monitor, tracks the error budget, and shows both on the SLO dashboard tile and in the printable SLA report.
- Use the free SLA calculator to see what a target means in minutes, for example 99.9%.
- Triggers and adaptive latency alerts can warn about a slow degradation before it eats the budget.
SLO (service level objective): frequently asked questions
What is a typical SLO?
Many user-facing services use 99.9% or 99.95% availability over 28 or 30 days, often with a latency SLO such as 99% of requests under a few hundred milliseconds. The right value depends on users and dependencies.
Should the window be calendar-based or rolling?
Rolling windows, such as the last 28 days, react smoothly and suit engineering decisions; calendar months match billing and contracts.
What is the difference between an SLO and an SLA?
The SLO is the internal target; the SLA is the external promise with consequences. Set the SLO stricter so you notice trouble before the SLA is at risk.