SLIs, SLOs & Error Budgets

"The service should be reliable" isn't something you can measure or argue about consistently. SRE breaks that vague goal into three specific, related terms.

SLI: the measured number

A Service Level Indicator is a concrete, measured metric - "percentage of requests that returned successfully in the last 5 minutes," "percentage of requests served in under 200ms." It's just a number your monitoring already produces, same as the metrics from the Observability track.

SLO: the target for that number

A Service Level Objective is the target you set for an SLI - "99.9% of requests succeed, measured over a rolling 30 days." It's an internal goal, something the team aims for and designs around.

SLA: the SLO with a contract attached

A Service Level Agreement is what happens when an SLO gets a consequence attached for an external customer - "99.9% uptime, or you get a service credit." Not every SLO needs to be an SLA; plenty of internal targets never get a contract wrapped around them at all.

Error budget: how much unreliability is allowed

If the SLO is 99.9%, the error budget is the remaining 0.1% - the amount of unreliability you're explicitly allowed before you've broken your own target. This reframes incidents from "bad" in the abstract to a specific, trackable resource being spent:

• Budget healthy (plenty of the 0.1% left) → ship new features at normal velocity; some risk is fine.
• Budget nearly exhausted → freeze risky changes, shift focus to reliability work, until it recovers.

This is what makes error budgets genuinely powerful: they turn "reliability vs. shipping speed" from an endless argument into a number both sides already agreed to in advance.

Try it

curl -I https://api.example.com/health

When you're ready, hit Mark complete and move to the next lesson.