SLAs, SLOs, and Error Budgets: How to Promise Reliability Without Lying

A SLA is the external promise you make to customers, backed by a penalty. A SLO is the internal target engineering builds to, usually stricter than the SLA. A SLI is the actual measurement behind both. The error budget is the amount of unreliability you're allowed to spend — on deploys, migrations, and risk — before you breach the SLO.

Quick Answer: SLA = the promise (external, contractual). SLO = the target (internal, engineering's goal). SLI = the measurement (the metric that proves it). Error budget = 100% minus your SLO, spent deliberately on shipping speed instead of treated as a shameful gap.

Why "99.9% uptime" is not a specification

A number like 99.9% uptime sounds precise, but on its own it's not a specification — it's a slogan. Without a defined SLI (what's measured), a measurement window (monthly? annually?), and a scope (which endpoints, which regions), two teams can both claim 99.9% while experiencing wildly different customer pain.

The fix is separating three distinct artifacts that get sloppily merged into one conversation:

• SLI (Service Level Indicator): the actual metric — e.g., "percentage of /checkout requests returning under 400ms with a 2xx status, measured every 60 seconds."
• SLO (Service Level Objective): the internal target for that SLI — e.g., "99.95% of requests meet the SLI over a rolling 30 days." This is engineering's contract with itself.
• SLA (Service Level Agreement): the external, contractual promise — usually looser than the SLO, with a stated remedy (service credits, refunds) if missed.

Google's Site Reliability Engineering book (the source most of this vocabulary traces back to) is explicit that the SLA should be less strict than the SLO, which should be less strict than what you actually deliver day to day. That gap is deliberate headroom — not padding, insurance.

Why the gap between SLA and SLO matters

The gap absorbs noise. If your SLA is 99.9% and your SLO is 99.95%, engineering has room to make mistakes, run a risky migration, or eat an unplanned incident without triggering customer-facing penalties. Set SLA equal to SLO and you've deleted your own safety margin — the first bad week becomes a breach-of-contract conversation instead of an internal retro.

The nines table: what each decimal actually costs

Reliability targets read like rounding errors until you convert them into downtime a human would notice. This is the conversion PMs should memorize before they ever accept — or propose — a number in a contract.

Each additional nine is roughly a 10x reduction in allowed downtime — and, in practice, a far more than 10x increase in engineering cost. Going from three nines to four nines typically means eliminating entire classes of single points of failure: multi-region failover, zero-downtime deploys, aggressive circuit breakers, on-call staffing to match. This is the same nonlinear-cost pattern behind most infrastructure decisions — see how the web works: a PM's mental model for the request/response and infrastructure basics underneath these numbers.

The question every PM should ask before promising a nine

Before agreeing to "four nines" in a sales contract, ask: what does the last nine actually buy the customer, and can we verify it? A B2B tool used during business hours doesn't need five-nines infrastructure to satisfy real user experience — it needs an SLA that matches how customers actually use the product, backed by an SLI that measures the paths they actually hit.

Error budgets: reliability as a budget, not a binary

An error budget reframes reliability from a pass/fail promise into a spendable resource: if your SLO is 99.9%, your error budget is the remaining 0.1% — and that 0.1% is yours to spend on deploys, experiments, and calculated risk, not something to apologize for.

This is the single most useful mental shift in this whole topic. Most PM-engineering conflict over reliability isn't really about the target — it's about who gets to decide when to spend the budget, and that decision has been implicit and adversarial instead of explicit and numeric.

1. Calculate the budget. SLO of 99.9% over 30 days means ~43 minutes of acceptable "badness" that month.
2. Track burn rate. If an incident consumes 20 of those 43 minutes in one event, the team knows immediately how much room is left.
3. Set a policy for when the budget's exhausted. Google SRE's canonical rule: when the error budget runs out, feature launches pause and the team's priority shifts to reliability work until the budget replenishes.
4. Reset on a cadence. Budgets typically reset monthly or quarterly, matching the SLO's measurement window.

The reframe in one line: you're not asking "did we break our promise?" — you're asking "how much of our allowed unreliability have we spent, and on what?"

How error budgets resolve the speed-vs-stability argument

Without an error budget, "should we ship this risky change now" is a values argument — PM wants velocity, engineering wants caution, and neither side has a number to point to. With a budget, it becomes arithmetic: if there's budget left, ship; if it's exhausted, stabilize. Nicole Forsgren, Jez Humble, and Gene Kim's research behind Accelerate and the DORA metrics program found that elite-performing teams achieve both higher deployment frequency and lower change-failure rates simultaneously — reliability and speed aren't inherently opposed, they're a budget to allocate well.

This also reframes incidents themselves. An incident isn't purely a failure to mourn — it's a budget withdrawal with a size and a cause, which is a much easier conversation to have in a retro than "whose fault was the outage."

Choosing SLIs that actually reflect user experience

A good SLI measures what the customer experiences, not what's easiest for engineering to instrument — a mistake that quietly undermines everything built on top of it. Server uptime is easy to measure and often nearly useless; it can be "up" while every real user request times out downstream.

The SRE literature generally sorts useful SLIs into a handful of categories:

• Availability: proportion of valid requests served successfully.
• Latency: proportion of requests served faster than a threshold (often expressed as a percentile — p95, p99 — not an average, since averages hide the tail experience that frustrated users actually feel).
• Quality/correctness: proportion of responses that were not just fast and "200 OK," but correct — data modeling matters here, since a well-defined schema makes correctness checkable in the first place (see data modeling: from entities to a real schema for how weak data foundations turn into invisible reliability debt).
• Freshness: for pipelines and caches, how stale is the data compared to source of truth.

Where SLIs commonly go wrong

The most common failure isn't picking the wrong metric — it's picking a metric no one owns and no one can query on demand. An SLI buried in a dashboard nobody checks between incidents isn't an SLI, it's decoration. Treat the SLI definition itself as a first-class requirement, not an implementation detail engineering fills in after the fact.

Negotiating SLAs with engineering (and with customers)

The negotiation goes better when the SLA is treated as a joint output of a cost/risk conversation, not a number Sales promises before checking with anyone. PMs sit at the center of that translation — between what a customer will pay for, what a contract will state, and what engineering can defend with actual architecture.

A workable process looks like this:

1. Start from the SLI, not the number. Agree what's measured before debating what target to hit.
2. Price the gap. Ask engineering directly: what does it cost — in infrastructure, headcount, on-call burden — to move from the current reliability level to the proposed SLA plus its SLO buffer?
3. Segment by customer tier, if it's real for your business — an enterprise contract with a financial penalty clause deserves a different SLO than a free tier.
4. Write the SLA in customer language, the SLO in engineering language, and keep them explicitly linked so nobody discovers the gap during an incident.
5. Revisit on a schedule. Reliability requirements drift as usage scales; an SLO set for 10,000 users may be wrong at 10 million.

This is exactly the kind of cross-functional requirement that tends to get hand-waved as "highly available" in a one-line PRD bullet and then argued about for real during an incident retro. Reliability targets can be captured as explicit, testable requirements in Prodinja's Spec Studio — where a living PRD carries PR-style diffs and readiness gates — so "highly available" becomes a stated SLO with a defined SLI and error budget attached, instead of a hope nobody agreed on until it was tested by an outage. It's a place to make the negotiation above literally checkable at spec-review time, not a claim about an AI that runs the calculation for you.

Getting this requirement right early also protects against a specific flavor of technical debt — reliability corners cut under launch pressure that quietly compound; see technical debt, explained for your CEO for how to frame that tradeoff upward. And because reliability commitments are a technical-foundations topic alongside APIs and infrastructure basics, the technical foundations complete guide is a useful map of how this piece connects to the rest — including what an API actually is, for product managers, since most SLIs are measured at the API boundary.

Key Takeaways

• SLA, SLO, and SLI are three different artifacts, not synonyms: the external promise, the internal target, and the measurement behind both.
• The nines table converts abstract percentages into real downtime — 99.9% is ~8.7 hours a year; each added nine cuts allowed downtime roughly 10x while typically raising cost far more than 10x.
• An error budget turns reliability into arithmetic: 100% minus your SLO is a spendable allowance for risk, deploys, and experiments — not a shameful gap to hide.
• When the budget's exhausted, the policy — not a debate — decides: feature work pauses and the team shifts to stability until the budget replenishes.
• A good SLI measures user-experienced reality (latency percentiles, correctness, freshness), not an easy-to-instrument proxy like raw server uptime.
• SLAs should always be looser than SLOs, preserving headroom so ordinary operational noise doesn't trigger contractual penalties.
• Treat reliability targets as testable requirements at spec time, not a one-line adjective in a PRD, so the tradeoff is negotiated once instead of relitigated during every incident.