In a planning meeting, someone says Tiffin "should never go down". Everyone nods. It sounds like the right goal.
It isn't a goal at all, because nothing can meet it. Servers fail, cloud regions have bad days, a payment provider has an outage, and someone eventually ships a bug. "Never" gives the team nothing to plan against, and no way to tell whether this month went well. What you need instead is a number: how reliable is reliable enough, measured how, and what do you do when you miss it?
This module is about availability: keeping Tiffin working when parts of it break, all the way up to losing a whole region. It starts with picking that number.
Three terms that get mixed up
| Term | What it is | Tiffin example |
|---|---|---|
| SLI (indicator) | Something you measure, usually as good events / total events | Share of checkout requests that succeed |
| SLO (objective) | The target for that measurement, over a time window | 99.9% of checkouts succeed, over 30 days |
| SLA (agreement) | A promise to a customer, with a penalty if broken | Restaurants get a fee credit if the partner app is down more than 0.5% of a month |
The SLI is the thermometer. The SLO is the temperature you're aiming for. The SLA is a contract with money attached, so it's always set looser than the SLO. You want to know you're in trouble long before you owe anyone a refund.
A service level objective (SLO) is a target for how often a service does the right thing, measured from the user's side, over a fixed time window.