What Is a Service Level Objective (SLO)?

Last verified on Nov 8, 2026.

A service level objective is a promise you make to yourself. It says how good a service has to be, measured one specific way, over a stated period. If you do not write the number down, every outage becomes an argument about whether it was bad enough to matter.

The Definition

Google's SRE book defines an SLO as a target value or range of values for a service level that is measured by a service level indicator. The shape is simple: an SLI at or below an upper bound, at or above a lower bound, or inside a range. Everything else on this page follows from treating that sentence seriously.

A usable SLO has four parts:

• A measurement. The SLI, such as the share of requests that return a non-error response.
• A threshold. What counts as good, such as "under 300 ms".
• A target. The fraction of events that must be good, such as 99.9%.
• A window. The period the target is judged over, such as a rolling 28 days.

The SRE book's own example shows why a service can carry several targets for one indicator: 90% of Get RPC calls under 1 ms, 99% under 10 ms, and 99.9% under 100 ms. One number rarely describes the shape of a latency curve. It also suggests separate objectives when clients differ, such as a bulk pipeline that cares about throughput and an interactive caller that cares about latency.

An SLO Written Down

Keep SLOs in a short, reviewable document, not in someone's head. A format a team can paste into a repo:

name: checkout-availability
sli: 'checkout requests with status < 500 / checkout requests, excluding 4xx'
target: 99.9%
window: rolling 28 days
owner: payments-team
review: quarterly

name: search-latency
sli: 'search requests answered in under 300 ms / search requests'
target: 99%
window: rolling 28 days
owner: search-team
review: quarterly

The thresholds above are illustrations. They are not recommendations for your service.

What an Availability Target Allows

The target decides how much failure you can absorb. Here is the downtime each availability target allows over a 30-day month (43,200 minutes):

That gap is called the error budget: 100% minus the SLO, according to Google's workbook. Each added nine cuts the budget by a factor of ten, and usually costs far more than the last one.

How to Choose the Number

Google's guidance in the SRE book and workbook comes down to a few rules:

• Do not aim for 100%. The SRE book says it is probably never the right target. It is impossible to reach and typically more than users want or notice.
• Do not lock in today's performance by default. The book warns that it can commit you to an unnecessarily strict SLO. The workbook relaxes this: current performance is a fair starting point when you have nothing else, provided you revisit it.
• Keep the list short. Pick the few indicators that reflect what users care about. Too many targets and nobody tracks any of them.
• Leave a margin. Run an internal target tighter than anything you tell customers. See SLA vs SLO.
• Pick a window deliberately. The workbook says rolling windows follow user experience more closely, while calendar-aligned windows fit business planning. It suggests whole weeks, such as four, so every window holds the same number of weekends.
• Get agreement. The workbook asks for approval from all stakeholders and a process for refining the SLO over time. Otherwise, it says, compliance is just another KPI.

Your first SLO will be wrong. The workbook says that is acceptable: get something measured, then improve it with a feedback loop.

When the SLO Is Missed

An SLO only matters if missing it changes behavior. The usual policy is to slow feature work and spend the time on reliability until the service is back within target. That decision rule is what the error budget page covers. Alerting on the speed at which you are spending the budget, not on every blip, is how teams find out in time.

For the signals behind the numbers, see how latency spikes and performance degradation show up in logs, and Sazabi's reliability issue detection for the failures that burn budget quietly.