SLOs, SLIs, SLAs, and Error Budgets: The Complete Guide

SLO, SLI, SLA, error budget: the one-paragraph mental model

Four terms get used interchangeably and they should not be. Here is the whole relationship in one breath: you measure the service with an SLI, you aim that measurement at an SLO, the gap below the SLO is your error budget, and the SLA is the looser version you put in a contract. Get those four in the right order and almost everything else about reliability engineering falls into place.

Let us define each precisely. An SLI (service level indicator) is a quantitative measure of some aspect of the service, almost always expressed as a ratio of good events to valid events: the proportion of requests that returned successfully, or the proportion served faster than a latency threshold. It is a number between 0 and 100%, and it answers the question "how are we doing right now?"

An SLO (service level objective) is a target value or range for an SLI, measured over a window. "99.9% of requests succeed over a rolling 28 days" is an SLO. It is the internal line you hold yourself to. It is a promise to yourselves, not to customers, which is exactly why it can be honest and strict.

An SLA (service level agreement) is a contract with a customer that includes one or more SLOs plus the consequences of missing them, usually service credits or refunds. The SLA is the legal, external commitment. It is almost always looser than your internal SLO, for reasons we cover in section six.

An error budget is the inverse of the SLO: it is the amount of unreliability you are permitted before you breach the objective. If the SLO is 99.9%, the error budget is 0.1%. That small slice of allowed failure is not waste; it is the fuel that lets you ship changes, run experiments, and survive the dependencies you do not control. The error budget is the bridge between "we want it reliable" and "we want to move fast," because it turns that tension into a single spendable number.

Choosing the right SLI

The SLI is where most SLO programs succeed or fail, because if you measure the wrong thing the rest of the machinery faithfully optimizes the wrong thing. A good SLI tracks what your users actually experience, moves when they suffer, and stays flat when they do not. The classic formulation is a ratio:

There are four families of SLI that cover the vast majority of services:

Availability

The fraction of valid requests that succeed. The subtlety is defining "success." A 200 with a broken body is not a success; a 503 from a circuit breaker is a failure; a 400 caused by a genuinely bad client request is usually not counted against you. Decide what "good" and "valid" mean once, write it down, and measure consistently.

Latency

The fraction of requests served faster than a threshold, for example the share of requests under 300ms. Note that this is still a ratio of good events to valid events, not an average. Averages hide the tail; a threshold-based SLI keeps you honest about the slow requests that users actually notice.

Error rate

Closely related to availability but framed around the rate of failed operations, useful for asynchronous and batch workloads where there is no clean request/response. The good-events ratio still applies: successful jobs over total valid jobs.

Freshness (and correctness)

For data pipelines, caches, and replicas, the user-facing question is often "how stale is this?" A freshness SLI measures the fraction of data served within an acceptable age. Correctness and durability SLIs round out the set for storage-heavy systems.

What makes a good SLI, concretely: it is measured as close to the user as possible (ideally at the load balancer or the client, not deep in a backend); it has an unambiguous definition of good and valid; it moves with user pain and ignores things users never feel; and it is cheap and reliable to collect. The anti-pattern is the vanity SLI, such as CPU utilization or raw uptime of a host, which can look perfect while the product is unusable.

Setting the target: why not 100%, and the nines table

Once you have an SLI, you have to choose the number. The single most important rule is this: the target is never 100%. A 100% objective is impossible to sustain, costs exponentially more for each additional nine, and leaves zero error budget, which freezes all change because every deploy threatens the perfect record. The correct target is the lowest reliability that keeps your users happy, because reliability beyond what users can perceive is money set on fire.

How do you find that number? Work backwards from the user. Look at where complaints, churn, and abandoned sessions actually start. If users do not notice the difference between 99.9% and 99.99%, do not pay for the extra nine. If a single bad hour triggers a wave of support tickets, you need a tighter target. Start with a defensible estimate, watch real behavior, and tune it. An SLO is a living target, not a stone tablet.

The cost of each nine is exponential, and the allowed downtime collapses fast. Here is the canonical nines table, with allowed unavailability per period:

Read that table as a price list. Moving from 99.9% to 99.99% is not 10% more work; it is a different operational regime that usually demands redundancy, automated failover, and sub-minute detection and remediation, which is exactly the territory where automation stops being a nicety and becomes the only way to hit the number. For most teams a target in the 99.9-99.99% band is the honest, affordable sweet spot.

Error budgets and burn rate

The error budget is simply 1 minus the SLO, expressed over a window. If your SLO is 99.9% over 28 days, your budget is 0.1% of that window, which works out to roughly 40 minutes of allowed badness across those four weeks. That budget is a resource you get to spend on change: every risky deploy, every experiment, every flaky dependency draws it down, and when it refills at the start of the next window you get to spend again.

The key operational concept is burn rate: how fast you are spending the budget relative to the SLO window. A burn rate of 1 means you are on pace to exhaust exactly the budget by the end of the window, which is fine. A burn rate of 10 means you are spending ten times too fast and will run out in a tenth of the window. Burn rate is what turns a static target into a live signal.

Fast burn vs slow burn

Not all budget consumption is equal. A fast burn is a sudden outage chewing through the budget in minutes; it warrants paging someone immediately. A slow burn is a chronic, low-grade leak (a small but persistent error rate) that will exhaust the budget over days; it warrants a ticket, not a 3am page. Treating these the same is how teams end up either over-paged or blind to slow decay.

Multi-window, multi-burn-rate alerting

The modern way to alert on SLOs is not a static threshold but a combination of burn rate and time windows. You define a fast-burn alert that fires when, say, you have burned a large share of the budget over the last hour and the last five minutes confirm it is still happening. You add a slow-burn alert over a much longer window to catch chronic leaks. Pairing a long window for statistical confidence with a short window for freshness gives you alerts that are sensitive to real problems and resistant to noise. This is the single biggest upgrade most teams can make to their paging: stop alerting on causes and raw thresholds, start alerting on how fast the user-facing budget is burning.

Error-budget policy: what teams actually do when the budget is spent

An SLO without a policy is just a chart. The error-budget policy is the agreement, written and signed off by both engineering and product before any crisis, that says what happens when the budget runs out. Deciding this in advance is the whole point: nobody negotiates priorities in the middle of an outage.

The canonical policy is the feature freeze. When the budget is exhausted, the team stops shipping risky changes and redirects effort to reliability work until the budget recovers. It is blunt, it is effective, and it aligns incentives instantly: product now cares about reliability because unreliability blocks the roadmap.

A mature policy usually has several graduated clauses:

• Budget healthy: ship freely, run experiments, take reasonable risks. This is the budget doing its job.
• Budget low (for example under 25% remaining): require extra review on risky changes, slow down non-urgent deploys, and start prioritizing the reliability backlog.
• Budget exhausted: feature freeze. Only reliability fixes and critical security work ship until the budget recovers.
• Budget repeatedly blown: escalate to leadership; the target, the architecture, or the staffing is wrong and needs a decision above the team.

The policy only works if it has teeth and is honored by both sides. If product can wave through features during a freeze, the SLO is theater. The discipline is what converts a number on a dashboard into a real control over the speed-versus-reliability trade-off.

SLOs vs SLAs: internal target versus contractual promise

People conflate these constantly, but they serve opposite purposes. The SLO is your internal early-warning line. The SLA is the external cliff with money attached. The single most important rule that follows: your SLO should always be stricter than your SLA.

Here is why. If you set your internal SLO equal to your contractual SLA, the first time you learn you are in trouble is the moment you have already breached the contract and owe customers credits. There is no warning, no buffer, no time to react. By setting the SLO tighter, you build in a safety cushion: your internal error budget runs out, your policy triggers, and your team starts fixing reliability while there is still contractual margin left.

A common, healthy pattern: publish a customer-facing SLA of 99.9%, but hold an internal SLO of 99.95%. The 0.05% gap is your cushion. When you breach the internal 99.95% objective you go into reliability mode, but you have not yet missed the 99.9% you promised customers. The stricter SLO protects the looser SLA.

One more distinction: SLAs include consequences (credits, penalties, escalation paths) and are negotiated with legal and sales; SLOs are owned by engineering and exist purely to drive operational behavior. Never let the contract dictate your internal target. The contract is the floor you must never hit; the SLO is the line you defend so you never get close to that floor.

Common SLO mistakes

Most failed SLO programs fail the same handful of ways. Recognize these early.

Too many SLOs

The eager team creates an SLO for every metric on every service. The result is a wall of dashboards nobody reads and alerts nobody trusts. SLOs are expensive to maintain and only valuable if defended. Pick the few user journeys that matter and resist the urge to instrument everything.

Vanity SLIs

Choosing indicators that are easy to collect rather than meaningful to users: CPU, memory, raw host uptime, internal queue depth. These can sit at 100% while the product is down. Always ask: if this SLI is green, can a user still be in pain? If yes, it is the wrong SLI.

Alerting on causes, not symptoms

Paging on "disk is 80% full" or "CPU is high" generates noise and trains responders to ignore alerts, because most of those conditions never hurt a user. Alert on the symptom the user feels (the burn rate of a user-facing SLI) and let diagnosis find the cause. This single shift cuts page volume dramatically and raises trust in every remaining alert.

Setting the target by gut, then never revisiting it

A target plucked from the air and frozen forever is almost certainly wrong. Set it from user behavior, then tune it as you learn. An SLO that never changes is an SLO nobody is actually using.

An SLO with no policy

The most common failure of all: a beautifully measured SLO with no agreement about what happens when it is breached. Without a policy, breaching the SLO changes nothing, and the whole apparatus becomes decoration.

A 90-day plan to roll out SLOs

You do not roll SLOs out across an organization in a week. Here is a staged plan that gets one service to a defended, alerting, policy-backed SLO in a quarter, which then becomes the template for the rest.

The 10-point SLO checklist

Before you call an SLO done, run it past these ten points. If you cannot tick all ten, the SLO is not finished.

Frequently asked questions

Related guides

Go deeper into the reliability stack: site reliability engineering is the discipline SLOs come from; AI SRE and agentic SRE for how agents defend objectives; MTTR for the resolution metric error budgets pressure; alert fatigue for why burn-rate alerting beats threshold noise; incident management for the lifecycle a blown budget triggers; AI observability for the data SLIs are computed from; on-call for who carries the pager when the budget burns; self-healing infrastructure and AIOps for automating the response. See the Nova AI Ops feature set across detection, diagnosis, and auto-resolution.