What Is an SLO (Service Level Objective)?
Reviewed by Ionut Caval · Updated June 2026
A Service Level Objective (SLO) is the internal target a team sets for a particular service level, such as 99.95% uptime or a maximum response time, measured over a defined time window. It is the goal the team manages toward, usually set tighter than any customer-facing SLA to leave a safety margin.
A Service Level Objective (SLO) is a precise, internal reliability target that an engineering team commits to managing toward, for example "99.95% of requests succeed over a rolling 30-day window" or "99% of responses return in under 300 ms." It is the goal you steer by, sitting between the metric you measure and the promise you make to customers. An SLO has three parts: an SLI (the metric being measured), a target value (the percentage or threshold), and a time window (rolling 28 or 30 days is common). Without all three it is not actionable, since 99.9% means nothing until you say 99.9% of what, measured over how long.
SLO vs SLA: why the SLO is tighter
The SLO is internal; the SLA is the external, often contractual promise to customers, with credits or penalties when it is missed. Teams deliberately set the SLO stricter than the SLA so there is a buffer. If your SLA guarantees 99.9% uptime (about 43 minutes of downtime per month), you might run an internal SLO of 99.95% (about 22 minutes). The 21-minute gap is your safety margin: a bad week can burn the SLO without breaching the customer SLA. For a full breakdown of what each "nine" of uptime allows, see what 99.9% uptime actually means.
Error budgets
The flip side of an SLO is the error budget: the small amount of failure the target permits. A 99.95% availability SLO leaves a 0.05% budget, roughly 22 minutes of allowed downtime in a 30-day month. Error budgets turn reliability into a spendable resource:
- When the budget is healthy, teams can ship faster and take more risk, since there is room to absorb a small failure.
- When the budget is nearly exhausted, the sensible response is to slow releases and prioritise reliability work until it recovers.
- A consistently overspent budget signals the SLO is too strict for current capacity, or that the system needs real investment.
Picking realistic SLOs and measuring the underlying SLIs from outside your infrastructure, the way a real visitor connects, is what keeps the target honest. Uptime and SLA monitoring records the availability data you need to track an SLO and prove an SLA.
See also: Uptime & SLA monitoring
Frequently asked questions
-
What is the difference between an SLO and an SLA?
An SLO is the internal target a team aims for, with no contractual consequences. An SLA is the external promise to customers, with remedies like service credits if it is missed. Teams usually set the SLO stricter than the SLA so a bad stretch does not immediately breach the customer agreement.
-
What is an error budget?
An error budget is the amount of failure an SLO allows. A 99.95% availability SLO permits 0.05% downtime, roughly 22 minutes over a 30-day month. Teams spend the budget on faster releases when reliability is healthy and freeze changes when it runs low.
-
How do you choose a good SLO target?
Base it on what users actually need and what your system can sustain, not on a round number. Set it tighter than your SLA to create a buffer, measure the underlying SLI from outside your infrastructure, and adjust the target if the error budget is constantly overspent or never touched.
-
What is the relationship between SLI, SLO and SLA?
The SLI is the measured metric (for example uptime percentage), the SLO is the target you set for that metric, and the SLA is the promise you make to customers based on it. The SLI tells you where you stand, the SLO is the goal, and the SLA is the commitment.
-
Put these metrics to work. Monitor your site free.
2-minute setup · Cancel any time
-
No credit card needed