Reliability targets Updated
SLI vs SLO vs SLA
An SLI is a measurement, an SLO is the target you set for it, and an SLA is a promise to customers with consequences if you miss it. The gap between perfect and the SLO is your error budget.
On this page
| Term | What it is | Example | Who cares |
|---|---|---|---|
| SLI indicator | A quantitative measure of service behaviour, ideally the ratio of good events to valid events. | Share of HTTP requests that return a non-5xx response in under 300 ms | Engineers |
| SLO objective | A target value for an SLI over a time window. | 99.9% of requests are good, measured over a rolling 30 days | Engineering and product |
| SLA agreement | A contract that states a service level and the remedy (often service credits) if it is missed. | 99.5% monthly uptime, or a 10% credit | Customers, legal, sales |
| Error budget | The allowed amount of unreliability: 1 − SLO. | 0.1% of requests, about 43 minutes of full outage per 30 days | Everyone who ships changes |
Service level indicators
The most useful SLIs are expressed as a ratio so they always fall between 0% and 100%:
SLI = good events ÷ valid events × 100%
“Valid” lets you exclude events that should not count, such as requests rejected for bad credentials or health-check traffic. Typical SLI types:
| Type | Good event | Fits |
|---|---|---|
| Availability | Request served without a server-side error | APIs, web front ends |
| Latency | Request served faster than a threshold (e.g. 300 ms) | Interactive services |
| Freshness | Data read was updated within a threshold (e.g. 10 minutes) | Pipelines, caches, replicas |
| Correctness | Output matches the expected result | Pipelines, billing, search |
| Throughput / coverage | Record processed within the expected time | Batch and stream processing |
| Durability | Stored object is still retrievable | Storage systems |
Express latency as “share of requests faster than X” rather than as a percentile. To combine instances, sum the good events and the valid events separately, then divide; don’t average per-instance ratios or percentiles, which weights a quiet instance the same as a busy one.
Where to measure
Measure as close to the user as you can afford. Server-side application metrics are easy but miss failures before the request reaches your code. Load balancer logs catch more. Synthetic probes and real-user monitoring catch the most, at higher cost and noise. Many teams start at the load balancer and add probes for critical journeys.
Service level objectives
An SLO has three parts: the SLI, the target, and the window.
- Rolling windows (e.g. the last 30 days) match what users experience and suit alerting. Pick a whole number of weeks, such as 28 days, if your traffic has a strong weekly pattern.
- Calendar windows (e.g. each month) line up with business reporting and SLAs, but the budget resets abruptly, which encourages risk at the start of the period.
Example SLO specification
| Service | Checkout API |
|---|---|
| SLI (availability) | Valid requests are load balancer requests to /api/checkout/*, excluding those rejected for missing or invalid credentials. Good requests are valid requests that return a non-5xx status. SLI = good ÷ valid. Status codes miss timeouts the client gives up on and wrong answers served with 200, so add probes or checks for those. |
| SLI (latency) | Valid requests completed in 500 ms or less ÷ valid requests |
| Targets | 99.9% availability; 99% latency |
| Window | Rolling 28 days |
| Alerting | Multiwindow burn-rate alerts page the checkout on-call |
| Policy | See the error budget policy |
| Review | Quarterly, owned by the checkout team and its product manager |
Choosing the target
- Never 100%. It is unachievable, leaves no budget for change, and users cannot tell the difference beyond a point.
- Start from history. Use the last few weeks of SLI data as a baseline, then decide whether users need better or can accept worse.
- Respect dependencies. Your SLO cannot exceed what your hard dependencies deliver; see composite availability.
- Few and meaningful. One to three SLOs per user journey is plenty. If an SLO miss would not change any decision, drop it.
- Iterate. Revisit targets when user complaints and SLO data disagree.
SLO examples by service type
The error budget means something different for each kind of service. These four examples contrast availability, latency, freshness and batch SLOs. The targets are illustrative, not recommendations; each budget link opens the calculator with the same inputs.
| Service | SLI: good events ÷ valid events | SLO | Window | Error budget |
|---|---|---|---|---|
| Payments APIavailability | Requests with a non-5xx status ÷ valid requests, at the load balancer | 99.95% | 30 days | 20,000 failed requests of 40,000,000, or 21m 36s of full outage |
| Searchlatency | Successful requests served within 100 ms, and within 400 ms, ÷ successful requests | 90% ≤ 100 ms 99% ≤ 400 ms | 28 days | 10% of requests slower than 100 ms; 1% slower than 400 ms |
| Product cataloguefreshness | Catalogue reads that see data updated in the last 30 minutes ÷ catalogue reads | 99% | 28 days | 1% of reads may be stale, or 6h 43m 12s of fully stale data at steady read traffic |
| Nightly invoice runbatch | Runs that finish by 06:00 UTC ÷ scheduled runs | 97% | 90 days | 2 late runs of 90 |
Availability: payments API
A request-based SLO counts failures, not minutes, so the budget is 20,000 failed requests out of 40,000,000. The time figure, 21m 36s, holds only if the service fails completely while traffic is steady. With the Workbook’s starting-point fast-burn page (2% of the budget in one hour), this SLO pages when more than 0.72% of requests fail; see burn-rate alerting. Status codes miss requests that never reach the load balancer, so add a synthetic probe for the payment journey.
Latency: search
Two grades capture both the typical experience and the slow tail: a service where 90% of requests are fast but the rest take 10 seconds would pass a single 90% target and still annoy many users. Each grade is its own SLO with its own budget. Count failed requests in the availability SLO rather than here, so a fast error page does not improve the latency SLI. If you measure with histograms, put bucket boundaries exactly at 100 ms and 400 ms.
Loose targets change how you alert. At 90%, the one-hour fast-burn page would need 134.4% of requests to be slow, which is impossible (the calculator shows it as unreachable). Page on the 99% grade, which fires above 13.44% slow requests, and rely on the longer-window alerts for the 90% grade.
Freshness: product catalogue
Measure freshness where the data is read: each reader checks the timestamp of the data it receives and counts whether it was within 30 minutes. A periodic query over the whole table is simpler, but treats a record nobody reads as equal to one on the home page. Pipeline freshness SLOs usually take one of three forms: X% of data processed within Y minutes, the oldest data no older than Y, or the pipeline job completed within Y. Measure end to end, from input to what users read, not per pipeline stage.
Batch: nightly invoice run
A daily job produces one event a day, so the arithmetic is coarse. At 99% over 30 days, the budget is 0 late runs: one miss breaks the SLO. A longer window or a lower target gives a usable budget: 97% over 90 days allows 2 late runs. Burn-rate alerts do not suit so few events; alert on the run itself, for example when it has not started on time or is behind its usual progress. Pair it with a correctness SLO, since an invoice run that finishes on time with wrong totals can do more harm than a late one. To use the calculator for runs, enter them as requests.
Service level agreements
An SLA is a business decision with legal and financial consequences. Keep it looser than the internal SLO, so the team reacts to an SLO miss long before a contract is breached. SLAs often exclude planned maintenance and customer-caused failures and are usually measured per calendar month. If there are no consequences, it is not an SLA, it is a published SLO.
Common mistakes
- Using CPU, memory or pod restarts as SLIs. They are causes, not user experience; monitor them, but do not set SLOs on them.
- Averaging latency. Averages hide the slow tail that users notice.
- Setting SLOs without a policy. Without an agreed response to budget exhaustion, an SLO is only a dashboard.
- Alerting on every SLI dip. Alert on budget burn rate instead; see burn-rate alerting.
- Copying the SLA into the SLO. That leaves no warning margin.
Sources: Google, Site Reliability Engineering, ch. 4 “Service Level Objectives”; The Site Reliability Workbook, ch. 2 “Implementing SLOs” (SLI types, multi-grade latency SLOs, pipeline freshness measurement) and ch. 13 “Data Processing Pipelines” (freshness and correctness SLOs, end-to-end measurement).