SLA vs SLO vs SLI: Reliability Targets Explained with Examples.

"We guarantee 99.9% uptime" is a sentence that hides three different ideas: what you measure, what you aim for, and what you promise. Site reliability engineering gives them separate names - SLI, SLO and SLA - and keeping them separate makes reliability decisions much easier.

Key takeaways

• SLI is a measurement, SLO is an internal target for it, SLA is a promise to customers with consequences.
• Set the SLA looser than the SLO so you notice trouble before you owe anyone anything.
• The error budget (100% minus the SLO) tells you how much risk you can still take this month.
• Measure from the user's side - external monitoring - not only from inside your servers.

SLI: what you measure

A service level indicator is a number that reflects how users experience the service, usually a ratio of good events to all events:

• Share of HTTP checks that succeeded.
• Share of API requests answered in under 500 ms.
• Share of scheduled jobs that finished on time.

A good SLI is measured where users are. An uptime monitor checking from several cities is a direct SLI for availability; CPU usage is not an SLI at all - users don't feel CPU, they feel errors and slowness.

SLO: what you aim for

A service level objective is a target for an SLI over a time window:

SLOs are internal. They exist to guide engineering decisions, so set them where users start to notice and care, not at 100%.

SLA: what you promise

A service level agreement is a contract. It names a target, how it's measured, what is excluded (usually announced maintenance) and what happens when it's missed - typically service credits.

Because an SLA has consequences, set it looser than your SLO. If your SLO is 99.95% and your SLA 99.9%, a bad month first burns your internal target and gives you time to react before you owe anything.

Error budgets

The error budget is the unreliability your SLO allows:

Teams use the budget to make trade-offs:

• Budget left? Ship features, run experiments, do risky migrations.
• Budget nearly spent? Slow releases down and spend time on reliability.

You can check what a target means in practice with the uptime calculator.

Choosing realistic targets

• Start from history. If you measured 99.7% last quarter, promising 99.99% next month is wishful thinking.
• Count your dependencies. A service that relies on three components each at 99.9% can't be more available than about 99.7% unless you have redundancy.
• Every extra nine costs more. Going from 99.9% to 99.99% means detecting and fixing problems in minutes, around the clock.

Measuring it honestly

Your SLI is only as good as its data:

1. Measure from outside - external checks see DNS, network and certificate problems that internal metrics miss.
2. Check often enough - a 5-minute interval can't measure a 4-minute monthly budget.
3. Confirm failures from more than one location so one bad network path doesn't burn your budget.

Frequently asked questions

• Do small teams need SLOs?

  +

  A simple one helps: "the shop is reachable 99.9% of the time". It turns vague arguments about reliability into a number you can check every month.

• Is 100% uptime a good SLO?

  +

  No. It leaves no room for any change and is impossible to meet in practice. Pick the level at which users stop noticing problems.

• Where does the SLA measurement come from?

  +

  From whatever the contract names - often the provider's own monitoring. Keeping your own independent external monitoring lets you verify the figure.