SLA vs SLO vs SLI: what is the difference?

In what order should you set SLIs, SLOs and an SLA?

Once customers pay, "it is usually up" stops being an answer. They will ask what you promise, and you should know what you measure before you promise anything. The order matters: pick the indicators, set objectives a little stricter than any agreement, and only then sign an SLA.

What makes a good SLI?

A good SLI measures what users feel, ideally from their side, as the OpenTelemetry primer puts it. Google's SRE book lists the usual ones: availability, often counted as the share of well-formed requests that succeed; latency, how long a response takes; error rate, as a share of all requests; and throughput, in requests per second.

Measure latency as a percentile, not an average. The SRE book's example is a service whose typical request takes about 50 ms while 5% of requests are about 20 times slower, a gap an average hides. The 99th percentile shows the plausible worst case; the median shows the typical one.

How do you tell an SLA from an SLO?

Ask what happens if the target is missed. The SRE book's test: if there is no explicit consequence, it is an SLO. An SLA carries one, most often financial, such as a rebate or a service credit. So an SLA belongs with your terms and your lawyer, while SLOs are an engineering tool you can adjust as you learn.

How much downtime does each level of nines allow?

Each extra nine cuts the allowed downtime roughly tenfold. In a 30-day month, 99% availability allows 7 hours 12 minutes of downtime, 99.9% allows 43 minutes 12 seconds, 99.95% allows 21 minutes 36 seconds, and 99.99% allows only 4 minutes 19 seconds. The table adds the yearly figures.

What is an error budget, and when is it spent?

The gap between 100% and your SLO is your error budget, the unreliability you can afford. Google's SRE book describes it as the budget of how much unreliability is remaining. While budget remains, ship; when it runs out, slow releases and fix reliability first.

What mistakes do teams make when setting SLOs?

The usual SLO mistakes are copying today's performance into the target, promising absolutes, tracking too many objectives, leaving no safety margin between the internal target and the advertised one, and overachieving for years until users depend on it. Google's SRE book warns against each of them, for the reasons below.

• Copying today's performance into the target. The SRE book warns this can lock you into heroic efforts to keep it.
• Promising absolutes such as always available, which are unrealistic and expensive.
• Tracking too many. Choose just enough SLOs to cover what users care about.
• No safety margin. Keep the internal SLO tighter than the one you advertise, so you fix chronic problems before customers notice.
• Overachieving for years. Users come to depend on the reliability you actually deliver, not the one you wrote down.

In a Lovable or Supabase app the first SLI is usually the share of API requests that succeed and how fast the slowest ones are, which needs observability in place first. Our production readiness check shows whether you can measure it yet, and each plan states its own support response times.