The SLI / SLO / SLA Framework

Table of Contents#

1. Why This Topic Comes Right After "What Is SRE"
2. SLI — Service Level Indicator, In Depth
3. Choosing Good SLIs — A Worked Framework
4. SLI Examples Across Different System Types
5. SLO — Service Level Objective, In Depth
6. The Mathematics of "Nines"
7. Rolling Windows vs Calendar Windows
8. Multiple SLOs and Composite SLOs
9. Writing a Formal SLO Document
10. SLA — Service Level Agreement, In Depth
11. Real-World SLA Examples
12. The SLI/SLO/SLA Relationship — Full Picture
13. Common Mistakes and Interview Traps
14. Worked Practice Problems
15. Summary and What's Next

---

Why This Topic Comes Right After "What Is SRE"#

Part 1 established the core premise: SRE treats reliability as a measurable, budgetable feature rather than an unlimited requirement. This part makes that premise fully precise. Every SRE interview — whether for a startup or a FAANG-scale company — will spend meaningful time on SLI/SLO/SLA and error budgets, because these concepts are the operating system of an SRE organization: everything else (monitoring, alerting, incident response, capacity planning, even how much automation work gets prioritized) is downstream of "what does 'reliable enough' mean for this system, and how do we know if we're meeting it?"

Diagram

---

SLI — Service Level Indicator, In Depth#

An SLI is a carefully defined, quantitative measure of some aspect of the level of service provided. It's the raw, measured number — the input to everything downstream.

The Formal Definition#

An SLI is a carefully defined quantitative measure of some aspect of the level of service that is provided.

Most SLIs, especially for request/response services, are expressed as a ratio of two numbers: the number of "good" events divided by the total count of valid events, expressed as a percentage.

SLI = (number of good events / number of valid events) × 100

This ratio form has a critical property: it naturally produces a number between 0% and 100%, which is intuitive for setting targets (SLOs) and is directly comparable across services, even ones that are otherwise unrelated.

Anatomy of a Well-Specified SLI#

A proper SLI specification has several distinct parts that interviewers expect you to be able to name:

Diagram

Interview trap: candidates often conflate the specification (what counts as good/valid, conceptually) with the implementation (how you actually compute it). A senior answer separates these explicitly: "the specification is what we agree on with stakeholders; the implementation is an engineering detail that can change (e.g., switching from log-based metrics to a service mesh sidecar) without changing what we've promised."

Where to Measure an SLI — The Critical Decision#

The measurement point dramatically affects what the SLI actually represents.

Diagram

Common interview question: "If you only measure your SLI at the application layer, what could you be missing?" Expected answer: outages where the request never reaches the app at all — DNS failures, load balancer outages, network partitions, or a fully-down region — because from the app's point of view, those requests simply don't exist in its logs. This is why many mature orgs also run synthetic/blackbox probes from outside their infrastructure as a cross-check.

---

Choosing Good SLIs — A Worked Framework#

Good SLIs share several properties. Use this as a checklist both for real work and for structuring interview answers.

Diagram

Anti-patterns (things that look like SLIs but aren't good ones)#

The "User Journey" Method for Deriving SLIs#

A widely used practical technique (from the SRE Workbook) is to map out the critical user journeys through your system, then derive an SLI for each critical step.

Diagram

For each step, ask: "What would a user consider broken here?" That answer becomes the "good event" definition for that step's SLI.

---

SLI Examples Across Different System Types#

Different kinds of systems need different SLI shapes. Interviewers sometimes probe this by asking about a system type you haven't explicitly prepared for (e.g., "how would you define an SLI for a batch pipeline?") to see if you understand the method, not just memorized examples.

Request/Response Services (APIs, Web Apps)#

Copy
sli_availability:
  good_events: "http_status NOT IN (500, 502, 503, 504)"
  valid_events: "all requests excluding synthetic health checks"

sli_latency:
  good_events: "latency_ms < 300"
  valid_events: "all successful requests"

Data Pipelines / Batch Processing#

For batch systems, "good" isn't about a single request — it's about freshness and correctness of output.

Copy
sli_freshness:
  good_events: "pipeline_completion_time - data_arrival_time < 30 minutes"
  valid_events: "all scheduled pipeline runs"

sli_correctness:
  good_events: "rows processed without schema validation errors"
  valid_events: "all rows in the batch"

Storage Systems#

Storage systems typically care about durability (did we lose data) separately from availability (can we read/write right now).

Copy
sli_durability:
  good_events: "objects still retrievable and uncorrupted"
  valid_events: "all objects ever stored"
  # Often expressed in extreme nines: 99.999999999% (11 nines) — because
  # data loss is effectively permanent and irreversible, unlike a transient
  # availability blip.

sli_availability:
  good_events: "successful read/write API calls"
  valid_events: "all read/write API calls"

Streaming / Real-Time Systems#

Copy
sli_end_to_end_latency:
  good_events: "event processed within 2 seconds of ingestion"
  valid_events: "all ingested events"

sli_message_loss:
  good_events: "messages delivered exactly once"
  valid_events: "all messages published"

Why Durability SLIs Use So Many More "Nines"#

A quick sanity check that's a great interview answer: availability incidents are usually recoverable (retry, wait, failover — the data comes back). Durability incidents are usually not (data is permanently gone). Because the cost of failure is qualitatively different (temporary inconvenience vs. permanent loss), storage systems justify far stricter targets — Google Cloud Storage and AWS S3 both advertise 99.999999999% (11 nines) annual durability, while their availability SLAs sit around 99.9%-99.99%.

---

SLO — Service Level Objective, In Depth#

An SLO is a target value or range of values for a service level that is measured by an SLI. It's the number your team commits to internally.

SLO = SLI target over a defined measurement window

Full example: "99.9% of /api/checkout requests will complete successfully with latency under 400ms, measured over a rolling 28-day window."

Why SLOs Are Not Set at 100%#

This is arguably the single highest-value concept to be able to explain fluently in an SRE interview. Three independent reasons, all worth citing:

Diagram

A strong interview answer includes a concrete cost curve intuition: going from 99% → 99.9% might mean adding retries and a secondary replica (relatively cheap). Going from 99.9% → 99.99% might require multi-region active-active architecture, sophisticated failover automation, and dramatically more testing (expensive). Going from 99.99% → 99.999% might require custom hardware, specialized on-call staffing, and extreme operational discipline (very expensive) — for a gain of about 4 minutes of downtime per year that most users would never notice anyway, since client devices and networks fail far more often than that.

Setting an SLO — A Practical Process#

Diagram

Common mistake: setting the SLO to match current performance exactly, or worse, setting it aspirationally above current performance with no plan to get there. If your service has historically run at 99.5% and you set an SLO of 99.99% because "that's what good services have," you'll be perpetually in breach on day one, which makes the error budget meaningless (nobody trusts an "always red" dashboard) and demoralizes the team.

---

The Mathematics of "Nines"#

Being able to do this math instantly, without a calculator, is a very common interview screening question.

The Quick Mental-Math Trick#

You don't need to memorize the whole table — memorize the derivation method:

Allowed downtime = (1 - SLO) × total time in window

For a 30-day month = 43,200 minutes:

• 99.9% → (1 - 0.999) × 43,200 = 0.001 × 43,200 = 43.2 minutes
• 99.99% → 0.0001 × 43,200 = 4.32 minutes
• 99% → 0.01 × 43,200 = 432 minutes ≈ 7.2 hours

Notice the pattern: each additional nine divides the allowed downtime by 10. This single fact lets you reconstruct the whole table live in an interview.

Diagram

---

Rolling Windows vs Calendar Windows#

Rolling Window (e.g., "trailing 28 days")#

Diagram

• Always looks at the trailing N days from "now," so it smoothly slides forward every day.
• Advantage: an incident on day 27 doesn't suddenly "disappear" from the budget calculation at an arbitrary calendar boundary — the budget consumption smoothly fades out of the window over time.
• Advantage: avoids the psychological effect of "we get a fresh 100% budget on the 1st" which can encourage risky releases right after a reset.
• 28 days (exactly 4 weeks) is a common choice specifically because it always contains the same number of each weekday, avoiding weekday/weekend traffic pattern skew that a 30-day window would introduce.

Calendar Window (e.g., "this month," "this quarter")#

• Resets on a fixed schedule (1st of the month, start of quarter).
• Advantage: aligns naturally with business reporting cycles, SLA billing credits, and quarterly planning.
• Disadvantage: an incident on the 30th and an incident on the 2nd of the next month look "independent" for reporting purposes even if they're related, and a genuinely bad month can be "forgiven" the moment the calendar flips.

Interview answer template: "I'd use a rolling window for internal engineering SLOs, since it gives a smoother, more honest signal for day-to-day decision-making. I'd use a calendar window only where required for external reporting/billing purposes tied to an SLA."

---

Multiple SLOs and Composite SLOs#

Real services almost never have just one SLO. A typical production service might track:

Diagram

Composite / Aggregate SLOs#

Sometimes you need a single SLO for a multi-step user journey, where each step has its own underlying SLI. A common approach: define the journey's SLO as the probability that every step succeeds.

Composite SLO ≈ SLO(step1) × SLO(step2) × SLO(step3) × ... × SLO(stepN)

Worked example: a checkout journey has 3 steps, each individually meeting 99.9%:

0.999 × 0.999 × 0.999 ≈ 0.997 (99.7%)

This is a critical, frequently-tested insight: chaining multiple 99.9%-reliable services together produces a worse composite reliability than any individual step — this is exactly why microservice architectures need to be more reliable per-service than a monolith would need to be, to deliver the same end-to-end user experience. This also motivates the use of graceful degradation and fallback patterns (covered in the Reliability & Architecture Patterns tutorial) so that one failing dependency doesn't necessarily fail the whole journey.

Diagram

---

Writing a Formal SLO Document#

Mature SRE orgs maintain SLOs as living documents (often as YAML/config-as-code, checked into version control alongside the alerting rules they generate). A full worked example:

Copy
service: checkout-api
owner: payments-team
last_reviewed: 2026-06-01

slos:
  - name: availability
    sli:
      description: "Fraction of checkout requests that succeed"
      good_events_query: |
        sum(rate(http_requests_total{service="checkout-api", status!~"5.."}[5m]))
      valid_events_query: |
        sum(rate(http_requests_total{service="checkout-api"}[5m]))
    target: 99.95
    window: rolling_28d
    consumers:
      - mobile-app
      - web-frontend

  - name: latency_p99
    sli:
      description: "Fraction of requests faster than 400ms"
      good_events_query: |
        sum(rate(http_request_duration_seconds_bucket{service="checkout-api", le="0.4"}[5m]))
      valid_events_query: |
        sum(rate(http_request_duration_seconds_count{service="checkout-api"}[5m]))
    target: 99.0
    window: rolling_28d

error_budget_policy:
  healthy_threshold: 25%      # >25% budget remaining -> normal velocity
  warning_threshold: 10%      # <25% -> increase review rigor
  freeze_threshold: 0%        # <=0% -> freeze non-critical releases
  escalation: "#checkout-oncall Slack channel + eng-director review"

Why interviewers like seeing this: it demonstrates you understand SLOs as operational infrastructure — not a slide in a slide deck, but a config that literally generates dashboards and alerts (this connects directly to the multi-window burn-rate alerting covered in the Observability tutorial).

---

SLA — Service Level Agreement, In Depth#

An SLA is a business/legal contract with (usually external) customers that includes explicit consequences if a service level isn't met. Internally, SLAs are often simplified to: "An SLA is an SLO with a penalty attached."

SLA = SLO(s) referenced in a contract + defined consequences for breach

Key Differences From SLOs#

Why the Internal SLO Should Be Stricter Than the External SLA#

Diagram

If the internal SLO and external SLA were identical, the team would have zero margin for error — the moment engineering's own target is breached, customers are already owed money. By keeping the internal SLO tighter, the team gets an early warning (their own error budget policy engages) well before there's any risk of an actual contractual/financial consequence.

---

Real-World SLAs From Major Cloud Providers#

Grounding this in real numbers is a great way to show depth in an interview.

Interview tip: you don't need exact up-to-date figures (they change) — what matters is being able to reason about the pattern: multi-AZ/multi-region configurations get higher SLAs than single-instance ones, durability SLAs for storage are far stricter than availability SLAs, and credits scale with breach severity rather than being all-or-nothing.

Service Credit Structure (Typical Pattern)#

Diagram

---

The SLI/SLO/SLA's Relationship — Full Picture#

Diagram

The Analogy, Fully Extended#

"SLI is the speedometer reading right now. SLO is the speed limit you set for yourself — maybe stricter than the law, to stay safe. SLA is the actual legal speed limit — the one a police officer enforces, where breaking it gets you a ticket (a fine — the service credit). You want your personal limit (SLO) to kick in well before you're anywhere near the legal one (SLA), so you never actually get the ticket."

---

Common Mistakes and Interview Traps#

---

Worked Practice Problems#

Problem 1: Your service has an SLO of 99.9% over a rolling 28-day window. It's day 10 of the window, and you've already had 30 minutes of downtime. Are you on pace to breach the SLO?

Solution: Total budget for 28 days = 0.001 × 28 × 24 × 60 = 40.32 minutes. At day 10, a sustainable pace would have consumed (10/28) × 40.32 ≈ 14.4 minutes. You've consumed 30 minutes — more than double the sustainable pace. Burn rate ≈ 30 / 14.4 ≈ 2.08x. You are burning budget roughly twice as fast as sustainable, and at this rate you'd exhaust the full 40.32-minute budget by around day 13-14, well before the 28-day window closes. This should trigger a warning-tier response.

Problem 2: A composite user journey has 4 sequential dependencies, each individually at 99.95%. What's the approximate end-to-end SLO?

Solution: 0.9995⁴ ≈ 0.9980 → ~99.80%, noticeably worse than any individual component's 99.95%. This is why the end-to-end journey SLO should be defined and tracked as its own top-level SLI (via synthetic transactions through the whole flow), not inferred from individual service SLOs alone.

Problem 3: Your storage system SLA promises 99.999999999% (11 nines) durability but only 99.9% availability. A customer complains their file was "unavailable for an hour" — is this an SLA breach?

Solution: No — durability and availability are separate SLIs/SLAs. An hour of unavailability, while inconvenient, doesn't necessarily indicate any data loss (durability breach). As long as the file was retrievable after the availability incident resolved, durability was never at risk. This is exactly the distinction interviewers probe to see if you understand that "reliability" isn't one single number.

---

Summary and What's Next#

• SRE = applying software engineering discipline to operations, with reliability treated as a measurable, budgetable feature rather than an unlimited requirement.
• SLI = the raw, quantitative measurement (a ratio of good events to valid events), ideally measured as close to the real user as possible.
• SLO = the internal target for that SLI, deliberately set below 100% based on cost/benefit tradeoffs, typically tracked over a rolling window.
• SLA = the external, contractual version of an SLO, with financial consequences, usually set looser than the internal SLO to provide a buffer.
• Composite (multi-step) journeys have lower effective reliability than any single component — reliability multiplies down a chain, it doesn't average.
• Durability and availability are distinct concepts with very different acceptable failure rates.

Continue to Part 3 (03-error-budgets.md) to see how the SLO becomes an actionable, spendable error budget that drives day-to-day engineering decisions.