Define reliability in numbers — SLIs, SLOs, and error budgets

At a glance

Learning objectives

• Define an SLI and an SLO for a data property like freshness or completeness
• Compute an error budget and state what burning it permits and forbids
• Borrow the incident and postmortem loop for data platform failures

What you need

• A pipeline whose users can tell you what late or wrong data costs them
• A calendar window for the SLO (28 days is the default)

Steps

1. Take the vocabulary from the source — Google's SRE books cover SLIs/SLOs/error budgets, incident management, postmortem culture, and capacity planning, and data platform teams already borrow from them when they define data SLAs and run incident drills. (from ref-sre-google )
2. Know why these books are canonical — they are called the origin of most SLO and postmortem vocabulary used in data reliability work, so using their terms keeps your design review intelligible to SREs. (from ref-sre-google )
3. Point the toolkit at data properties — the books are the vocabulary source reliability engineering lends to data teams, so your freshness metric is an SLI, your freshness promise is an SLO, and the slack between them is a budget. (from ref-sre-google )
4. Read the originals, they are free — the SRE books are published free online, so there is no paywall between your team and the chapter that defines the error budget policy you are about to adopt. (from ref-sre-google )
5. Line the SLOs up with the architecture review — AWS's best-practice guidance is organized around Well-Architected pillars, and a written SLO is what turns the reliability pillar from prose into a number you can fail. (from ref-aws-arch-center )

Check yourself

• You can state one SLI, one SLO, and one error budget for a table you own — and what the on-call is allowed to do while the budget holds.
• An incident on your platform ends in a postmortem with a follow-up, not in a restart and a shrug.

Worked example

Data SLI candidates (pick 1-2 per pipeline):
  - freshness    : now - max(event_time) in the serving table
  - completeness : rows_loaded / rows_expected from source count
  - success rate : successful runs / scheduled runs over 28d

SLO:    freshness p95 <= 15 min
        success rate >= 99.0% over 28 days

Budget: 1 - SLO = 1% of 28d = ~6.7 h of failed schedule per month
Burned  -> freeze risky changes; intact -> ship.

Sourced from

• Google SRE Books
• AWS Architecture Center

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• An SLA without a measured SLI behind it is a liability, not a promise.
• Budget exhausted and still shipping — that is how small failures compound into the big one.
• A postmortem that ends with 'be more careful' has found no mechanism and fixed nothing.

Production considerations

• Track budget burn on the same dashboard as freshness and completeness.
• Run one incident drill per quarter using a past failure as the script.

Diagram

sli / slo / error budget
   |
   |- SLI  --> measured property (freshness p95, completeness ratio)
   |- SLO  --> promise on the SLI (freshness p95 <= 15 min over 28d)
   |- budget --> 1 - SLO  = allowed failure
   |
   |- budget intact   --> ship risky changes
   |- budget burned   --> freeze, stabilize, postmortem
   |
    --> capacity planning closes the loop (SRE books)

Registry stats