What Is an SLO? A Practical Guide for Engineering Teams
Summary
A Service Level Objective is a measurable reliability target your team sets for itself. Not a customer contract, not a raw metric: an SLO translates vague reliability expectations into a specific, trackable number. This guide covers the difference between SLIs, SLOs, and SLAs, how error budgets make those targets operationally useful, and the practical steps for setting your first SLO without defaulting to a number that has no relationship to current service behavior.
What is an SLO? A service level objective (SLO) is an internal reliability target your team sets for itself. Not a contract with customers, not a raw metric from your observability stack. An SLO answers one question: how reliable does this service need to be, and how will we measure it?
A complete SLO looks like this: 99.9% of HTTP requests to /api/checkout return a success status and complete within 300ms, measured over a rolling 30-day window. Three components: the measurement, the target, and the window. All three matter.
SLI, SLO, SLA: Three Abbreviations That Mean Different Things
These three terms appear together constantly. Teams use them interchangeably. They describe different things.
An SLI (Service Level Indicator) is the raw measurement your monitoring system produces. Error rate as a percentage of total requests. P99 latency in milliseconds. Percentage of successful database writes. The SLI is the number that comes out of Datadog, Grafana, or whatever stack you are running. It tells you what happened.
An SLO (Service Level Objective) is the goal you define on top of the SLI. It answers: of all the possible values this SLI can take, which range counts as acceptable? If your SLI is error rate and your SLO is "error rate below 0.1% for 99% of five-minute windows," then you have a pass/fail test, not just a number on a dashboard.
An SLA (Service Level Agreement) is the external version of the same logic, with contractual consequences. Your SLA might say "99.5% uptime or we issue a 20% service credit." Your SLO should sit above that threshold, so your team knows about a degradation before the SLA breach becomes a customer conversation.
The gap between SLO and SLA is not padding for carelessness. It is a designed margin that converts "we are trending toward a breach" into "we have time to fix this now."
One more important distinction: SLIs are measured continuously, but SLOs are evaluated over a window. The same error rate measured over seven days versus 30 days produces very different pass/fail results. A single bad hour matters a lot in a seven-day window. In a 30-day window, it is roughly one percent of the period. Choosing the right window is as important as choosing the right target.
Why "How Reliable?" Is Not a Complete Question
Before picking a number, you need to understand what the user experiences when the service degrades. "We need five nines" is a statement of ambition, not a measurement. A checkout API at 99.999% availability means roughly 26 seconds of errors per month. For a service processing ten transactions per second, that might be acceptable. For a service handling real-time financial settlement, it might not be.
The right SLO depends on two factors: the user impact of a degradation, and the operational cost of maintaining a tighter target.
If your service has logged 99.3% availability over the last 90 days, starting your first SLO at 99.9% is aspirational, not calibrated. The practical approach: pull the last 90 days of SLI data, set the SLO slightly tighter than current performance, then review quarterly. A 99.5% SLO with a real error budget policy beats a 99.9% SLO that gets ignored every time it breaches.
Common SLO targets by service type:
User-facing APIs (checkout, auth): 99.9% availability, P99 latency under 500ms
Internal services (data pipelines, batch jobs): 99.5% success rate, measured on job completion
Admin tooling: 99% availability is often sufficient
Background workers: SLO on job completion time rather than HTTP status
When picking which SLI to measure, use the four signals from Google's SRE book as a starting point: availability (did the request succeed?), latency (how long did it take?), throughput (how many requests is the system handling?), and error rate (what fraction failed?). Not every service needs all four. Most teams get real signal from availability plus one latency percentile. Adding more SLIs before you have a reliable baseline for the first two is a common way to create noise without gaining insight.
The Error Budget: From Target to Operating Decision
An error budget is the mathematical inverse of your SLO. If your availability SLO is 99.9%, then 0.1% of requests over the measurement window are allowed to fail. For a service receiving one million requests per month, that is 1,000 failed requests before the SLO is breached.
The error budget makes SLOs operationally useful. Without it, an SLO is a threshold that gets violated and then discussed. With an error budget policy, it becomes a decision framework.
When the error budget is healthy, say 80% remaining with two weeks left in the window, the team can ship fast. New features, experiments, riskier deployments are all in bounds. The error budget is the signal that speed is not currently the constraint.
When the error budget is burning down, the team shifts. Non-critical changes go on hold. The deployment policy tightens. Reliability fixes get prioritized. The error budget made the decision, not a manager judgment call about whether things "feel stable enough."
A concrete scenario: a checkout service had a 12-minute degradation on a Tuesday afternoon, consuming 15% of the monthly error budget. A second incident on Thursday consumed another 12%. At 27% consumed in the first week of the month, the error budget policy triggers: no new feature deployments until a postmortem is complete and the root cause is patched. That decision is not a product/engineering negotiation. It is a read from the data.
Google published its error budget policy in the SRE Workbook: a single incident consuming more than 20% of the quarterly error budget requires a postmortem. That is one concrete policy to adapt.
Burn rate alerts take this further. Instead of waiting until the error budget is nearly gone, a burn rate alert fires when the rate of consumption suggests you will exhaust the budget before the window ends. If your service is consuming error budget at 14 times the normal rate, you will exhaust a 30-day budget in roughly 50 hours. An alert at that rate gives the team two days to respond rather than a postmortem notification after the breach. Tools like Datadog and Grafana support multi-window, multi-burn-rate alerting out of the box. Setting it up takes an afternoon. Not having it means discovering SLO breaches after customers already noticed.
Setting Your First SLO Without Getting the Number Wrong
The most common mistake is starting with the target before establishing the measurement.
Step 1: Define the SLI. "Availability" is not an SLI. "HTTP requests returning a non-error status (2xx/3xx), divided by all HTTP requests" is an SLI. The measurement must be producible from telemetry you already have. Promising to instrument something "soon" means the SLO has no data source.
Step 2: Pull historical data. Look at the last 60 to 90 days. What does the SLI actually look like? What were the two or three worst days? This tells you what target is achievable today and how much headroom you have before the first breach.
Step 3: Set the measurement window. Rolling 30-day windows are the most common and give you responsive, always-current data. Calendar-month windows create cliff effects at month boundaries. Seven-day rolling windows are more sensitive but can trigger too frequently for teams still building reliability muscle.
Step 4: Write the error budget policy before you need it. At what error budget burn rate does the team pause non-critical changes? At what burn rate does the on-call escalate? Document this before the incident, not during it.
Step 5: Start with one service. Defining SLOs for 15 services at once produces 15 dashboards nobody reads. Start with the most user-visible service, run one quarter, adjust, then expand.
Measurement window options and their tradeoffs:
7-day rolling: fast feedback, more sensitive to short incidents, can create alert fatigue
30-day rolling: most common, balances signal and noise
90-day rolling: useful for infrequent but critical operations like batch jobs
A worked example: for an e-commerce API, you might set your first SLO as "95% of requests to /checkout succeed and return within 500ms, measured over a rolling 28-day window." That gives you a concrete SLI (success rate combined with latency), a specific target (95%), and a defined window (28 days). From there, you calculate the error budget: 5% of total requests may fail or be slow. If you receive 200,000 requests per day, your monthly error budget is roughly 280,000 failed requests before the SLO is breached.
Where SLO Monitoring Connects to Codebase Work
An error budget burning faster than expected is a codebase problem more often than an infrastructure one. Latency spikes trace back to N+1 queries that went unnoticed in code review. Availability drops trace back to a null pointer exception in a code path that only triggers under a specific load combination. The SLO detects the symptoms. The codebase contains the cause.
This is where the time between "alert fires" and "root cause identified" becomes the practical constraint. When the checkout service is consuming 30% of its error budget in three days and the on-call engineer has to grep across a 150,000-line monorepo to find the retry logic that is behaving differently under load, the SLO is doing its job. The tooling for root cause analysis is not.
Teams that have instrumented AI-assisted code search alongside their observability stack report significantly shorter time-to-diagnosis during incidents. A natural-language query for where the payment service handles retries on 503 responses surfaces the relevant function in seconds rather than the 20 minutes it takes to read across five files and one Confluence page. The 43-minute error budget window gets spent on fixing the issue, not on reading the code.
Four Ways Teams Get SLOs Wrong
Too many SLOs. A team tracking 12 SLOs simultaneously will treat alerts as background noise within two months. Three to five SLOs focused on the most user-visible behaviors is a workable ceiling for a team of 10 engineers. If you need more, organize them in tiers: critical SLOs that trigger error budget policies, and informational SLOs that just generate data.
Measuring infrastructure, not user experience. CPU utilization, memory usage, and disk I/O are useful debug signals. They are poor SLIs unless you can prove they directly correlate with user-visible degradation. Measure what the user experiences: request success rate, response time at P95 or P99, time to render the first meaningful piece of data.
SLOs set without operational cost analysis. Achieving 99.99% availability typically requires active redundancy, multi-region failover, and immediate on-call response at any hour. If the team cannot sustainably operate that way, the SLO will be breached regularly and then ignored. A breached-and-ignored SLO is worse than no SLO: it trains the team to dismiss reliability alerts.
Using error budget data to assign blame. If the first response to a consumed error budget is identifying who shipped the change that caused it, reporting will stop being honest. Error budgets are a team resource. When the budget runs low, the question is "what do we fix?" not "who is responsible?"
The organizational health test: would you share your current error budget status in an engineering all-hands without it triggering a political discussion? If not, the culture around SLOs needs more attention than the targets themselves. Reliability metrics work as decision tools only when the team trusts that reporting a problem does not create a personal risk.
SLOs Need Quarterly Reviews, Not Annual Ones
Setting an SLO is not a one-time calibration. Services change, traffic patterns shift, and the cost of maintaining a given reliability level changes with them.
Every 90 days, run through four questions:
Did the SLO hold? If yes, was it comfortable, suggesting the target could be tighter?
Did the error budget get fully consumed? What incidents drove that?
Did the SLO surface useful signal, or did the team override the error budget policy?
Is the measurement window still appropriate for how the service is being used?
If the team overrode the error budget policy more than twice in a quarter, the SLO is probably miscalibrated. Either the target is too tight, the window is too short, or the measurement is not reflecting what users actually experience.
SLOs are calibration tools. They are meant to be adjusted as reliability improves, as traffic grows, and as the business changes its tolerance for downtime. A team that reviews and adjusts its SLOs quarterly is running a reliability practice. A team that set them once and has not touched them since has a dashboard with numbers that mean nothing to anyone.