A service level objective (SLO) is a measurable target for the reliability of a service, expressed as the proportion of good events over a defined time window, for example 99.9% of requests succeed within 300 ms over 30 days. In observability, the SLO turns raw telemetry into a statement of whether users are getting acceptable service.
An SLO sits between two neighboring concepts. The service level indicator (SLI) is the measurement itself, and the service level agreement (SLA) is a contractual promise with consequences. The SLO is the internal engineering target, normally stricter than any SLA, and it defines the error budget that teams can spend on change and risk.
How an SLO is built from indicators
Every SLO has three parts: an SLI that classifies events as good or bad, a target percentage, and a compliance window. The SLI is best written as a ratio, good events divided by valid events, so the SLO reads naturally as a percentage.
Common SLI types follow what users actually experience. Availability counts requests that did not fail; latency counts requests faster than a threshold; freshness measures how recent processed data is; correctness and throughput apply to pipelines and batch systems. An SLO should describe the user journey, such as checkout or login, rather than an internal component such as CPU load.
| SLI type | Good event definition | Example SLO |
|---|---|---|
| Availability | Request returns a non-5xx response | 99.9% over 30 days |
| Latency | Request completes under a threshold | 95% under 200 ms, 99% under 1 s |
| Freshness | Data updated within a time limit | 99% of reads see data under 10 minutes old |
| Correctness | Output matches expected result | 99.99% of records processed correctly |
| Durability | Stored data remains readable | Objectives often expressed in many nines |
Measurement location matters. SLIs taken at the load balancer capture most server failures, while client-side or synthetic measurements also reveal network and front-end problems but are noisier.
Targets, windows and the error budget
The SLO target directly determines how much unreliability is tolerated. The error budget is simply one minus the target: a 99.9% SLO allows 0.1% of events to be bad. Expressed as time for an availability SLO, each additional nine shrinks the budget tenfold.
| SLO target | Error budget | Over 30 days | Over one year |
|---|---|---|---|
| 99% | 1% | About 7.2 hours | About 3.65 days |
| 99.5% | 0.5% | About 3.6 hours | About 1.8 days |
| 99.9% | 0.1% | About 43 minutes | About 8.8 hours |
| 99.95% | 0.05% | About 22 minutes | About 4.4 hours |
| 99.99% | 0.01% | About 4.3 minutes | About 53 minutes |
Rolling windows, commonly 28 or 30 days, give a continuous view and avoid a sudden reset that encourages risky behavior at the start of a period. Calendar windows align with business reporting and SLAs. Many teams track both.
The budget becomes a decision tool through an error budget policy. While budget remains, teams ship features freely; when it is exhausted, they slow or freeze risky releases and prioritize reliability work until the window recovers.
SLO, SLI and SLA compared
The three terms are often confused, yet they serve different audiences and purposes. Keeping them distinct avoids writing contracts around metrics nobody measures, or targets nobody can meet.
| Concept | What it is | Owner | Consequence of a miss |
|---|---|---|---|
| Service level indicator | A measured ratio of good events | Engineering | None by itself |
| Service level objective | Internal target for the SLI | Engineering and product | Error budget policy applies |
| Service level agreement | Contractual commitment | Business and legal | Credits, penalties or termination rights |
A sound practice is to set the SLO tighter than the SLA, for example an internal 99.95% behind an external 99.9% promise. The gap provides early warning before contractual obligations are at risk.
Alerting on SLOs with burn rates
SLOs change alerting from symptom thresholds to budget consumption. The burn rate is how fast the error budget is spent relative to the rate that would exactly exhaust it at the end of the window; a burn rate of 1 uses the whole budget in 30 days, while a burn rate of 14.4 consumes about 2% of a 30-day budget in one hour.
The widely used multiwindow, multi-burn-rate approach pages a person only for fast burns confirmed over both a long and a short window, and opens a ticket for slow burns. This reduces alert fatigue while still catching both sudden outages and gradual degradation. Tools such as Prometheus with Grafana, Datadog and dedicated SLO platforms implement these rules from the same SLI queries.
Common mistakes when defining SLOs
SLO programs fail more often from poor definitions than from poor tooling. Experienced teams watch for these errors:
- Aiming for 100%, which leaves no error budget and makes every change a violation.
- Measuring infrastructure instead of users, such as CPU or pod restarts, which do not show user impact.
- Too many SLOs per service, which dilutes attention; three to five per critical journey is usually enough.
- Copying targets from a provider SLA without checking whether dependencies can support them.
- Never revisiting targets, although they should be reviewed as traffic and expectations change.
- Averaging latency instead of using percentile thresholds, which hides the slowest requests.
A practical starting point is to measure current performance for several weeks, set the SLO slightly below observed reliability, and tighten it only when users or the business demonstrably need more.
Explained without jargon
A service level objective is a promise a team makes to itself about how well a service should work. It is like a bus company deciding that 99 out of 100 buses must arrive within five minutes of the timetable.
Because perfection is impossible, the target also defines how many late buses are acceptable. If too many run late, the company stops changing routes and fixes punctuality first. The essential idea is a clear, measurable line between good enough and not good enough.
A typical use case
An online payments team defines an SLO for its card authorization API: 99.95% of requests succeed and 99% finish under 500 ms, measured at the load balancer over a rolling 30 days. The error budget allows roughly 22 minutes of full unavailability per window, or an equivalent share of failed or slow requests.
Midway through the month, a new database driver causes intermittent timeouts. The burn-rate alert fires because the service is consuming its budget about ten times faster than sustainable. The on-call engineer rolls back the release, and the error budget policy pauses further deployments for that service until the remaining budget recovers. The outcome is a data-driven release freeze that both product and engineering accept, because the rule was agreed in advance.