vault

Service Level Objectives

24 min read

Service Level Objectives

Service-Level Indicators (SLIs), Service-Level Objectives (SLOs), and Service-Level Agreements (SLAs) are the three layered concepts the Site Reliability Engineering (SRE) discipline uses to make reliability quantitative, measurable, and contractual. An SLI is a measurement: a numerical fact about service behavior — for example, “the fraction of HTTP requests that returned 2xx within 200ms over the last 5 minutes.” An SLO is a target for an SLI — for example, “99.9% of HTTP requests return 2xx within 200ms over a rolling 30-day window.” An SLA is an external contract with consequences attached — for example, “if S3 availability falls below 99.9% in a billing month, AWS issues a 10% service credit.” The three are useless apart and powerful together: the SLI provides the data, the SLO provides the internal alarm, and the SLA provides the customer-facing commitment, with the SLO deliberately set tighter than the SLA so the team has buffer before contractual penalties kick in. The framework was popularized by the Google SRE Book (Beyer et al., 2016, Chapter 4) and codified into a complete operating model — including the error budget (error budget = 1 − SLO, the amount of unreliability the team is allowed to spend on velocity), burn-rate alerting (alert when the budget is being consumed faster than it can be replenished — see Alerting System Design), and the error-budget policy (what happens when the budget runs out: typically a deploy freeze and a forced reliability sprint). The deepest insight of the SLO framework is the rejection of “100% uptime” as a goal: above a certain reliability ceiling, every additional nine costs exponentially more, and clients of the service are themselves unreliable enough that they won’t notice — so over-delivering on reliability is a velocity-burning anti-pattern. Reliability is engineered to be just enough, not maximal.

1. Plain-Language Definition

The three terms — SLI, SLO, SLA — sound similar and get used interchangeably in casual conversation, which is the first source of confusion the SRE discipline tries to eliminate. Each refers to a distinct artifact, and the relationship between them is hierarchical.

A Service-Level Indicator (SLI) is a quantitative measurement of an aspect of the service that matters to users. It is a number you can graph. The Google SRE Book defines it as “a carefully defined quantitative measure of some aspect of the level of service that is provided” (Beyer et al. 2016, Chapter 4). Common examples: request success rate (the fraction of requests returning a non-error response over some window), request latency (typically expressed at a percentile — p95, p99, p99.9), throughput (requests per second sustained), data freshness (the lag between an event and its appearance in a downstream system), correctness (the fraction of pipeline outputs that match a known-correct reference), durability (the probability that a stored byte will still be retrievable after some interval). The SLI is just data — it does not contain a goal, only a measurement.

A Service-Level Objective (SLO) is a target value, or range of values, for an SLI, measured over a specific time window. It is the team’s internal commitment to itself about what level of service it will deliver. Phrased as an inequality: “SLI ≥ target over window.” For example: “p99 request latency ≤ 300ms over a rolling 28-day window,” or “request success rate ≥ 99.95% over a calendar quarter.” The SLO is what gets dashboards, alerts, and on-call attention. It is internal — customers may not know what your SLO is. The SLO exists to drive engineering behavior: when the SLO is at risk, you stop shipping features and fix reliability; when the SLO is comfortably met, you can spend the slack on velocity (more features, more experimentation, riskier deploys).

A Service-Level Agreement (SLA) is an external contract with consequences attached when an SLI falls below an agreed threshold. Consequences are typically service credits (refunds proportional to downtime), but for high-stakes contracts they can include termination rights or financial penalties. Critically, the SLA threshold is always weaker than the SLO threshold — the SLO is the trigger that says “we are at risk of breaching the SLA, do something.” The Google SRE Book is explicit: “If you don’t have an SLA, do you need an SLO? Maybe not. But you almost certainly want to” (Beyer et al. 2016, Chapter 4) — meaning many internal services have SLOs without SLAs, but a service with an SLA must have a tighter SLO behind it.

2. The Hierarchy and Why It Matters

The relationship between the three is a buffered cascade:

                 [ SLI: measured number, e.g. success rate today = 99.97% ]
                                       |
                                       v
              [ SLO: internal target, e.g. ≥ 99.95% over 30 days ]
                                       |
                                       v
              [ SLA: external commitment, e.g. ≥ 99.9% in billing month ]
                                       |
                                       v
              [ Penalty: e.g. 10% service credit if SLA breached ]

The SLO is strictly tighter than the SLA on purpose. If the SLA is 99.9% and the SLO is 99.95%, the team has a “headroom” of 0.05% — a window in which the SLO is breached (triggering internal alarm and the error-budget policy) before the SLA is breached (triggering customer credits and reputational damage). The SLO is the early warning. By the time the SLA threshold is reached, the team has already had a sustained period of internal alarm in which to react. This buffered design is the single most important reason SLOs exist — they are the upstream tripwire that prevents the downstream contractual damage.

The SLI sits underneath both, supplying the data. A team that has only an SLO without a defined SLI for it has a target without a measurement, which is operationally useless: there is no way to know whether the SLO is being met, only opinion. A team that has only an SLI without an SLO has a metric on a dashboard with no commitment attached — interesting, but it does not drive behavior, because nobody knows what value of the metric is acceptable. The three are co-required. In the SRE workbook (Beyer et al. 2018, Chapter 2), the recommended workflow is “pick an SLI, set an SLO, derive the error budget” — explicitly in that order.

3. Mechanism — How SLI Math Works

The most common SLI for a request-driven service is availability as the ratio of good events to total events:

SLI_availability = good_events / valid_events

Where:

  • good_events is the count of requests during the window that met the success criterion (e.g., HTTP status 2xx or 3xx, returned within 1000ms, not from a known-bad client).
  • valid_events is the count of requests during the window that should have been served (excluding, for example, requests during planned maintenance windows or requests from internal load tests).
  • The window is fixed (typically 28 or 30 days; rolling, not calendar-aligned, to avoid the “great month, terrible month” oscillation).

Phrasing the SLI this way — as a ratio of good/total events — is called the request-driven SLI pattern in the SRE workbook (Beyer et al. 2018, Chapter 2) and is the recommended template because it composes cleanly: latency SLOs (“99% of requests under 300ms”) and availability SLOs (“99.95% of requests succeeded”) can both be expressed as a count of “good events” over total. This unification is the basis for multi-window multi-burn-rate alerting described later.

For latency, the SLI is typically a percentile rather than an average:

SLI_latency = fraction of requests with latency ≤ T

For example, “99% of requests with latency ≤ 300ms” means: of all requests in the window, the 99th-percentile latency must be at or below 300ms. Averages are deliberately avoided here — averages mask the slow tail, which is exactly the part users feel. The SRE Book is emphatic on this: “Using percentiles for indicators allows you to consider the shape of the distribution and its differing attributes” (Beyer et al. 2016, Chapter 4).

flowchart LR
    A[Raw events: requests, samples] --> B[Classify: good vs bad vs invalid]
    B --> C[SLI = good / valid over window]
    C --> D{SLI >= SLO?}
    D -- yes --> E[Error budget OK; ship features]
    D -- no --> F[Error budget exhausted; freeze deploys; reliability sprint]

In the diagram above, the boxes represent stages of the SLO loop. Raw events flow in from instrumentation (each request, each sample). They are classified into good (met the SLI’s success definition), bad (failed it), and invalid (excluded entirely — synthetic checks, planned downtime, test traffic). The SLI is computed as the ratio of good to valid events over the chosen window. The result is compared to the SLO. The output of the comparison drives the error-budget policy: if the budget is intact, the team continues normal velocity; if the budget is exhausted, the team enters a controlled response that prioritizes reliability work over feature work. The arrow back from F to A is implicit — the policy response feeds back into the rate at which raw events are produced (fewer risky deploys), which in turn lets the SLI recover.

4. Origins — Google SRE and the Codification of Reliability

The vocabulary of SLI / SLO / SLA predates Google — telecom and enterprise IT had been using “SLA” since at least the 1980s — but the integrated framework with error budgets and burn-rate alerting is a Google invention, codified publicly in the Google SRE Book edited by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Murphy and published by O’Reilly in 2016 (sre.google/sre-book). The book’s Chapter 4 (“Service Level Objectives”) is the canonical reference; Chapter 3 (“Embracing Risk”) provides the philosophical underpinning — the explicit argument that 100% reliability is the wrong target, because it both costs too much and outpaces the reliability of the clients calling the service.

The pre-Google “SLA” world was largely contractual: enterprise contracts contained uptime promises with service-credit clauses, but there was little discipline about internal targets that were tighter than the contract, and almost no notion of an error budget as a positive thing to be spent. Google’s contribution was the inversion: the team should not aim for zero unreliability; it should aim for exactly the SLO, treating any reliability above the SLO as wasted velocity. Mark Roth and Ben Treynor Sloss articulated this as the error budget: error budget = 1 - SLO, and “if reliability is above the SLO, run more risky launches; if reliability is below the SLO, slow down and stabilize” (Beyer et al. 2016, Chapter 4).

A second wave of refinement came in the Site Reliability Workbook (Beyer et al. 2018, sre.google/workbook), which introduced multi-window multi-burn-rate alerting (Chapter 5, “Alerting on SLOs”, direct link). The workbook argued that the original “page when error rate > 0.1%” alerting was both noisy and slow — noisy because it fired on transient bursts, slow because by the time slow burns triggered it the budget was already gone. The modern recipe pages on a fast burn (alert when 2% of the 30-day budget is consumed in the last hour, page immediately) and a slow burn (alert when 10% of the budget is consumed in the last 6 hours, ticket but don’t page). This is the alerting model deployed in production at Google, Datadog (SLO Monitoring docs), Grafana, Prometheus (promtools.dev burn-rate alerts), and almost every modern observability platform. See Alerting System Design for a full treatment.

5. The Error Budget — Reliability as a Currency

The error budget is the most operationally consequential idea in the SLO framework. Mathematically it is trivial:

error_budget = 1 - SLO

If the SLO is 99.95%, the error budget is 0.05% of events over the window. Translated to wall-clock time for a continuously-running service, that is:

0.0005 * 30 days * 24 hours/day * 60 min/hour = 21.6 minutes per 30-day window

The team has 21.6 minutes of “downtime” (or its equivalent in degraded performance, partial failures, etc.) to spend per month before the SLO is breached. This budget is not a guilt mechanism — it is a resource. Risky launches should consume some of it; chaos engineering experiments should consume some of it; aggressive optimization that occasionally regresses should consume some of it. Spending the error budget is how the team converts reliability headroom into product velocity.

The key insight, articulated in the SRE Book Chapter 3, is that a budget that is never spent is a target that is too lax. If a team consistently ends each month with 90% of the error budget unspent, the SLO is wrong — the team is over-delivering on reliability, which means it is under-delivering on features (because reliability above the SLO has zero marginal value to the customer). The fix is to tighten the SLO until the budget gets spent. Conversely, if the budget is consistently exhausted in week 1 of a 4-week window, the SLO is too tight or the system is fragile, and the team needs to slow down or invest in reliability.

The error-budget policy is the explicit document, signed by both the SRE team and the development team, that specifies what happens when the budget is exhausted. A typical policy includes:

  • Deploy freeze for non-critical changes — only security and reliability fixes ship.
  • Mandatory postmortems for the incidents that consumed the budget.
  • Reliability sprint — engineers shift from feature work to fixing the top contributors to the budget burn.
  • Escalation path if the freeze doesn’t restore reliability within a defined window.

Without an error-budget policy, the SLO becomes a number on a dashboard that nobody acts on. The policy is what makes the SLO have teeth.

6. Worked Example — A Payment API with 99.95% SLO

Consider a payment processing API with the following published SLO: 99.95% of well-formed POST /charge requests succeed (return 2xx) within 500ms, measured over a rolling 30-day window.

Step 1 — Compute the error budget in event terms. Suppose the API serves 10,000 requests per second sustained, so the 30-day window contains:

10,000 req/s * 86,400 s/day * 30 days = 25,920,000,000 requests = ~2.6 * 10^10 events

The error budget is 1 - 0.9995 = 0.0005, so the maximum allowed bad events in the window is:

0.0005 * 2.592e10 = 12,960,000 bad requests

That is, the API may serve up to 12.96 million failures (5xx errors, latency

500ms, or other “bad” classifications) over the 30-day window before the SLO is breached.

Step 2 — Compute the error budget in time terms (only meaningful if traffic is roughly constant; for spiky traffic, only the event-budget is correct). At 10,000 req/s, 12.96M failures equals:

12,960,000 / 10,000 = 1,296 seconds = 21.6 minutes of total-failure-equivalent

This is the “downtime budget” if the failures are concentrated in continuous outage windows.

Step 3 — Burn-rate alert thresholds. Following the workbook (Beyer et al. 2018, Chapter 5), define two alert conditions:

  • Fast burn (page): If the last 1 hour of traffic is consuming the budget at a rate that would exhaust 100% of the 30-day budget in 36 hours, page immediately. Numerically, the fast-burn rate is 100% / 36h ≈ 14× the sustainable rate. If the per-hour error rate exceeds 14 * 0.0005 = 0.7%, page.
  • Slow burn (ticket): If the last 6 hours are consuming the budget at a rate that would exhaust 100% in 120 hours (5 days), open a ticket. The 5-day burn is 100% / 120h ≈ 6× sustainable. If the per-6-hour error rate exceeds 6 * 0.0005 = 0.3%, file a ticket.

Step 4 — Error-budget policy. Suppose on day 12 of the window, the team observes that 60% of the monthly budget has already been consumed by a faulty deploy that caused an hour of degraded performance. The policy kicks in: deploys are frozen for non-emergency changes; the team conducts the postmortem; a reliability sprint is opened. By day 30, if the team has held discipline, the budget refills (rolling window) and normal velocity resumes.

Step 5 — SLA implication. Externally, the team publishes an SLA of 99.9% (looser than the 99.95% SLO). Customers receive 10% service credit if availability over a calendar billing month falls below 99.9%. The 0.05% gap between SLO and SLA is the buffer that prevents customer-visible breaches. Even when the SLO has been violated for the month, the SLA is likely still intact, giving the team time to recover before customers are owed credits.

This worked example shows the entire SLO machinery in one frame: the event-level math, the time-level translation, the burn-rate alert configuration, the policy response, and the SLA buffer. Every production service deploying SLOs goes through a variant of this process.

7. Choosing SLIs by System Type

Different system types have different natural SLIs. The SRE workbook (Chapter 2) provides templates:

Request-driven systems (HTTP APIs, gRPC services, web applications): the natural SLIs are availability (fraction of requests with non-error responses) and latency (fraction of requests under a threshold). A typical SLO bundle: “99.9% of requests succeed AND 99% of successful requests complete within 300ms, both over 28 days.” Both indicators are needed because a service that returns 200 OK after 30 seconds is unavailable from the user’s perspective.

Pipeline / batch / streaming systems (data-processing jobs, ETL): the natural SLIs are freshness (the lag between an event happening and that event being reflected in the pipeline output), correctness (the fraction of records that pass a validation check), and throughput (the rate of records processed). A typical SLO: “99% of records pass freshness ≤ 10 minutes AND 99.99% pass correctness validation, over a 7-day window.” Latency does not apply directly because there are no requests; freshness is the equivalent.

Storage systems (object stores, databases, file systems): the natural SLIs are durability (the probability that a stored byte is still retrievable after T years — often given as “11 nines” or 99.999999999%), availability (fraction of read/write requests that succeed), and consistency latency (for replicated systems, the time until a write is visible everywhere). AWS S3 publishes 99.99% availability and 99.999999999% (11-nines) durability — durability is the absurdly tighter target because losing data is a categorically worse failure than failing a request.

Control-plane systems (orchestrators, schedulers, configuration services): the natural SLIs are success rate of operations and time-to-completion. For example, a Kubernetes scheduler might commit to “99.5% of pod scheduling decisions complete within 5 seconds, over a 24-hour window.”

Choosing the wrong SLI is one of the most common SLO failures (see Pitfalls). A common antipattern is measuring server-side success (the server returned 200) rather than user-perceived success (the user actually got a usable response) — see Sloss et al., NSDI ‘17, “Meaningful Availability”, which makes this exact argument.

8. Real-World Examples

Google customer-facing products publish target SLOs around 99.99% (four nines). The internal SRE team has stated that going beyond 99.99% (e.g., to 99.999%, five nines) for a service exposed over the public internet is generally meaningless, because public-internet packet loss alone is roughly 0.01% — the network swallows your fifth nine before users see it.

Internal infrastructure at Google (the components SREs build for other Googlers) often runs at higher SLOs than customer-facing services — 99.999% or higher — because dozens of services depend on the infrastructure and the reliability of each dependency multiplies. If you have 10 dependencies each at 99.99%, your composite reliability is 0.9999^10 ≈ 99.9%, which may be unacceptable for your own customer-facing 99.99% SLO. This is the calculus of service availability (ACM Queue, 2017).

AWS S3 publishes a 99.9% monthly availability SLA (s3 SLA) with service credits at 99.9%, 99.0%, and 95.0% breakpoints (10%, 25%, and 100% credit respectively). The internal SLO is tighter (not publicly stated, but observable from the actual measured availability, which usually exceeds 99.99%). The durability target is 99.999999999% (11 nines), which translates to a probabilistic guarantee that of 10 billion stored objects, you would expect to lose at most 1 per year on average. That number is achieved through erasure coding, multi-AZ replication, and regular integrity audits — see Amazon S3 Object Storage System Design for the architecture.

GitHub’s public status page reports SLAs for GitHub Enterprise customers; for example, GitHub Actions has a published 99.9% monthly availability SLA. Cloudflare publishes SLAs ranging from 99.99% (Enterprise tier) to lower tiers depending on plan. Stripe does not publish formal SLAs to most customers but does publish historical uptime; the unofficial SLO is widely understood to be in the 99.99%+ range.

Netflix is famous for not having traditional SLAs with consumers — the service is consumed via a fixed monthly subscription, so there is nothing analogous to “service credits.” Instead, Netflix relies entirely on internal SLOs and chaos engineering (Chaos Monkey) to discover reliability issues before customers do. The lesson: SLAs require something for the customer to be refunded; in subscription products with no per-request billing, SLOs alone do the work.

9. Tradeoffs

Tighter SLO ↔ Slower Velocity. Every additional nine of reliability roughly multiplies the engineering cost. Going from 99.9% to 99.99% means cutting allowed failure events by 10×, which usually requires more redundancy, more careful change-management, more investment in testing — all of which slow feature delivery. The SLO framework’s contribution is the explicit acknowledgement that this tradeoff exists and must be made deliberately, rather than implicitly through “make it more reliable” mandates from leadership.

SLA ↔ SLO Buffer Size. Setting the SLO 0.05% above the SLA gives a small buffer; setting it 0.5% above gives a larger buffer but also a stricter internal target. The bigger the gap, the more headroom the team has to detect and react before contractual penalties trigger — but the higher the floor of internal alarm, which may mean more frequent SLO breaches without corresponding customer impact. There is no formula for the right gap; the SRE Workbook recommends starting with “SLO is 25–50% tighter than SLA” and adjusting based on observed lead time between SLO breaches and would-be SLA breaches.

Strict Window vs Rolling Window. A calendar-month SLO (“99.9% in May”) is operationally simpler but creates a “fresh budget every month 1” effect — teams may take risks early in the month and be conservative later, or vice versa. A rolling window (“99.9% over the last 30 days”) smooths this out: every day, the oldest day rolls off and a new day is added, so the budget is continuously updating. Rolling windows are now industry standard for internal SLOs; calendar windows persist mainly in customer-facing SLAs because they align with billing cycles.

Aggregated vs Per-Customer SLOs. A 99.9% SLO across all customers can mask a situation where one customer has a 95% experience while everyone else has a 99.99% experience — the average looks fine. Per-customer SLOs (“each customer must see ≥ 99.5% over 30 days”) catch this, but require more complex monitoring infrastructure and may not be feasible at very high customer counts. Most teams compromise: aggregate SLO as the primary, plus a “worst customer” alert as a secondary signal.

10. Pitfalls

Choosing the wrong SLI. This is the most common and most damaging error. If your SLI measures “the load balancer returned 200” but the user experiences DNS failures, browser-side script errors, or CDN-layer rejections, your SLI claims 100% availability while users are seeing failures. The fix is to measure as close to the user as possible — synthetic checks from external monitoring services (Pingdom, Catchpoint), real-user-monitoring (RUM) instrumentation in browsers and apps, or “meaningful availability” metrics that account for the entire request path including the network (Sloss et al., NSDI ‘17). The SLI should answer “what fraction of users had a good experience,” not “what fraction of bytes left my server.”

Setting the SLO too loose. An SLO that is consistently met with massive budget left over is not driving any behavior. The team isn’t shipping faster (because it’s overengineering reliability they don’t need), and the SLO isn’t catching problems (because it’s looser than the actual reliability ceiling). Symptom: error budget at end of every window is > 80% intact. Fix: tighten the SLO until the budget gets meaningfully spent — this forces the team to choose between velocity and reliability rather than over-delivering on both.

Setting the SLO too tight. An SLO that is constantly breached produces alert fatigue, deploy freezes that the team learns to ignore, and an erosion of trust in the SLO process. Symptom: budget exhausted in week 1 every month. Fix: either invest in reliability work to actually meet the SLO, or loosen the SLO to a level the team can actually hold while still being meaningful to customers.

No error-budget policy. A team that has SLIs and SLOs but no documented policy for what happens when the budget is exhausted has built half the system. When the budget runs out, the team has no agreed response — typically managers and engineers argue about whether to keep shipping. The policy must be written before the first breach, signed by both the SRE and product leadership, and treated as binding. Without it, the SLO is theater.

Confusing uptime with availability. Traditional uptime (“the server process was running”) ignores degraded performance. A server that is up but returns errors for 50% of requests has “100% uptime” but 50% availability. Worse, a server that is up but takes 30 seconds to respond when the SLO is 500ms has 100% uptime, 100% success rate, and 0% latency-SLO compliance. The SLO framework’s insistence on event-based measurement (good events / total events) is precisely to fix this. Anyone who reports “uptime” instead of “availability” in 2026 is operating with 1990s-era reliability vocabulary.

Counting synthetic / health-check traffic as user traffic. Most systems serve a fraction of requests that are health checks from load balancers or synthetic probes. These are usually 100% successful (because they are designed to be cheap and predictable) and inflate the SLI. Filter them out at the SLI definition layer — count only “user-initiated” requests. The Site Reliability Workbook’s “valid events” concept (Chapter 2) exists precisely to formalize this exclusion.

Aggregating across endpoints with very different importance. A single SLO across “all API calls” treats /healthz (low-value, cheap) the same as /charge (high-value, expensive). A failed /healthz is annoying; a failed /charge is a customer’s money lost. Stratify SLOs by endpoint criticality — a tighter SLO for the critical endpoints, looser for incidental ones — or weight the SLI by request value if your business has well-defined per-request stakes.

11. Interview Discussion

In a system-design interview, SLOs come up most often when the interviewer asks “how do you know when this system is broken?” or “how do you alert on this?” — both of which are SLO-shaped questions. A strong answer walks through the three-layer hierarchy explicitly: “I’d define SLIs for [availability, latency, freshness, etc.], set SLOs at [target] over a [window], and alert on burn rate against the error budget.” Bonus points for naming the multi-window multi-burn-rate alerting pattern (Beyer et al. 2018, Chapter 5) by name.

Common follow-ups: “What’s the difference between SLA and SLO?” — answer with the buffer relationship: SLO tighter than SLA, SLO is internal alarm, SLA is external contract with consequences. “Should we aim for 100% availability?” — no, and articulate why: marginal cost of every additional nine grows exponentially, the network and clients impose their own reliability ceiling, and reliability above the SLO is wasted velocity. “How do you handle a service exhausting its error budget?” — describe the error-budget policy: deploy freeze, mandatory postmortem, reliability sprint, until the budget recovers.

Watch out for two common mistakes candidates make. First, claiming “we’ll have 99.999% availability” without articulating the cost — five nines is roughly 5 minutes of downtime per year, which is achievable only with multi-region active-active architectures (see Multi-Region Active-Active Architecture) and aggressive change management; throwing it out casually signals you haven’t thought about cost. Second, confusing the SLA with the SLO — using “SLA” loosely to mean “internal target” is a vocabulary error that experienced interviewers will flag. The discipline of using SLI/SLO/SLA in their precise senses is itself a signal of seniority.

Cross-references in interview answers: the alerting machinery for SLOs sits in Alerting System Design; the metric instrumentation that produces SLI data sits in Metrics and Monitoring System Design; the architectural choices that enable tight SLOs (multi-region replication, circuit breakers, retry budgets) sit in Multi-Region Active-Active Architecture; the recovery-targets cousin (RTO/RPO for disasters rather than ongoing reliability) sits in Recovery Objectives.

12. See Also

Graph View

Backlinks