Glossary
Service level objective (SLO)
An SLO is a service level objective: the reliability target a team sets for its own service, such as 99.9% of checks passing over 28 days.
Also called SLO, Service-level objective.
SLO stands for service level objective: the reliability target a team sets for its own service. The definition has three parts. There is an SLI, which is the measurement; a target for that measurement; and a window to measure it over. "99.9% of checks pass over a rolling 28 days" is an SLO. Over those 28 days, it allows 40m 19s of downtime before the objective is missed.
An SLO is not a contract, and nothing is owed to anyone when it is missed. That is the difference between an SLO and an SLA. The SLA is the promise made to customers, with a service credit attached if it is broken. The SLO is the target the team runs the service to, and it should be stricter than any SLA on the same service, by a visible margin. The gap is the time to notice a problem and fix it before a customer is owed anything.
The target sets the error budget: 100% minus the SLO, applied to the window. A 99.9% SLO leaves 0.1%. Counted in requests, that is 1 failed request in every 1,000. Counted in time, it is 40m 19s of downtime in 28 days. While budget remains, the team can keep shipping changes. Once it is spent, reliability work comes first. That rule is what makes an SLO useful, because it turns "is the service reliable enough?" into a number agreed in advance.
The most common mistake is a target of 100%, or one so close that missing it is routine. A target nobody meets stops being a signal, and 100% leaves no room for the one thing a reliable service needs most: shipping changes. Set the SLO at the level where users stop noticing failures, which is usually lower than engineers expect. Raise it only if the budget keeps going unspent.
| Example SLO | SLI it measures | What it allows |
|---|---|---|
| 99.9% of checks pass over 28 days | Availability: the share of checks that passed | 40m 19s of downtime |
| 99.5% of checks pass over 30 days | Availability: the share of checks that passed | 3h 36m of downtime |
| 99.9% of requests succeed over 28 days | Availability: requests answered without a server error | 1 failed request in every 1,000 |
| 95% of requests answered in under 300ms over 28 days | Latency: requests faster than a threshold | 1 slow request in every 20 |
| 99% of scheduled jobs finish over 30 days | Job success: runs that finished | 1 failed run in every 100 |
Questions
What is an SLO?
An SLO, or service level objective, is a reliability target a team sets for its own service. It names a measurement, a target and a window, such as 99.9% of requests succeeding over 28 days. Nothing is owed when it is missed. It decides whether the team works on features or on reliability next.
What does SLO stand for?
SLO stands for service level objective. It is one of three related terms. The SLI is the measurement, the SLO is the target set on that measurement, and the SLA is the contract with customers.
What is the difference between an SLO and an SLA?
An SLA is a promise to customers, written into a contract, with a service credit or refund if it is missed. An SLO is an internal target with no penalty. The SLO should be stricter than the SLA, so the team hears about a problem before any customer is owed anything.
What is an example of an SLO?
"99.9% of requests succeed over a rolling 28 days" is a common one. Counted in time, it allows 40m 19s of downtime in that window. Counted in requests, it allows 1 failed request in every 1,000. A latency SLO reads like "95% of requests are answered in under 300ms", which allows 1 slow request in every 20.
How do you choose an SLO target?
Start from what users notice, not from what the system can do. Look at the reliability the service has delivered recently, pick a target a little below it, and check that users were content at that level. Keep it stricter than any SLA you have signed, and avoid 100%, which leaves no budget for shipping changes.
Uptimely checks your services from outside and records whether each check passed and how long it took, so the availability behind an SLO is measured rather than estimated.
Start monitoring free →Related terms
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.