SLIs, SLOs and SLAs Explained with Real Examples

Why numbers matter

Imagine a product manager saying "the site feels slow" and an engineer replying "it looks fine to me". Both are right, and neither can win, because nobody has defined "slow" or "fine". Service level objectives replace opinions with an agreement that everyone can measure.

The three terms and how they fit

flowchart LR
  A[SLI<br/>what you measure<br/>good events / valid events] --> B[SLO<br/>internal target<br/>99.9% over 30 days]
  B --> C[SLA<br/>external promise<br/>99.5% with credits]
  B --> D[Error budget<br/>0.1% to spend]
  style A fill:#22d3ee,color:#012
  style B fill:#6366f1,color:#fff
  style C fill:#f87171,color:#fff

Keep the SLO tighter than the SLA. You want your own alarm to ring long before you owe anyone money.

Choosing good SLIs

An SLI is always a ratio: good events / valid events. That makes it a clean percentage between 0 and 100, and easy to compare with an SLO.

Pick SLIs from the user's journey, not from your servers. Users do not care about CPU; they care whether login works and checkout is fast.

Example SLIs in Prometheus

# Availability SLI: proportion of non-5xx responses
sum(rate(http_requests_total{job="api",code!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="api"}[5m]))

# Latency SLI: proportion of requests faster than 300 ms
sum(rate(http_request_duration_seconds_bucket{le="0.3",job="api"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="api"}[5m]))

Why percentiles beat averages

Suppose 100 requests: 99 finish in 100 ms and one takes 10 seconds. The average is about 200 ms, which sounds fine. But one in a hundred users waited ten seconds. A modern page makes dozens of requests, so most users will hit a slow one eventually.

xychart-beta
  title "Same traffic, very different stories (ms)"
  x-axis ["p50", "p90", "p95", "p99", "p99.9"]
  y-axis "Latency ms" 0 --> 3000
  bar [90, 180, 320, 1400, 2800]

Use p50 for the typical experience and p95/p99 for the tail. SLOs usually target a percentile, such as "95% of requests under 300 ms".

The nines table

Work it out yourself: 30 days × 24 h × 60 min = 43,200 minutes. At 99.9%, the allowed failure is 43,200 × 0.001 = 43.2 minutes.

How dependencies change the maths

Your service is only as reliable as the things it depends on.

flowchart LR
  U[User] --> A[Your API<br/>99.95%]
  A --> B[Database<br/>99.95%]
  A --> C[Auth service<br/>99.9%]
  A --> D[Payment provider<br/>99.9%]
  style A fill:#6366f1,color:#fff

If all four must work for a request to succeed (a serial chain), multiply: 0.9995 × 0.9995 × 0.999 × 0.999 ≈ 99.7%. Your own code could be perfect and you would still miss a 99.9% target.

If you have two independent redundant copies (parallel), failure requires both to fail: two 99% replicas give 1 − 0.01 × 0.01 = 99.99%.

Windows: rolling or calendar?

A rolling window (for example the last 30 days) forgives and forgets gradually, which matches how customers remember outages. A calendar window resets suddenly on the first of the month, creating cliffs: a terrible outage on the 31st is "forgotten" the next morning. Most SRE teams prefer 28 or 30-day rolling windows.

Setting an SLO: a practical recipe

flowchart TD
  A[List critical user journeys<br/>login, search, checkout] --> B[Define 1 to 3 SLIs each]
  B --> C[Look at 4 to 8 weeks of history]
  C --> D[Set the SLO slightly below<br/>what you achieve today]
  D --> E[Agree an error budget policy<br/>with product]
  E --> F[Review monthly,<br/>adjust quarterly]
  style D fill:#6366f1,color:#fff

• Start from history, not wishes. If you run at 99.6% today, an SLO of 99.99% is fantasy.
• Few SLOs per service. Two to four. More becomes noise.
• Do not reuse the SLA. Keep a buffer.
• Use the same measurement for everyone, so nobody argues about how it was computed.

Common mistakes

• Too many SLOs, so nobody remembers them.
• Averages instead of percentiles.
• Measuring server health instead of user experience.
• Targets copied from other companies.
• SLO = SLA, so there is no early warning.
• Counting synthetic traffic and health checks as real users.
• Defining SLOs and then never using them in decisions.

Objectives without contracts

Many important services have an SLO but no SLA. A public search engine, for example, has no signed contract with every user, yet the owning team still manages it with a target and a budget, because downtime costs reputation and revenue even when nobody can sue.

A practical test for telling the two apart: ask "what happens if we miss it?" If the answer is a refund or penalty, it is an SLA. If the answer is "we slow down and fix things", it is an SLO. SRE teams usually help define the SLIs behind an SLA, so everyone agrees on how it is measured, and leave the commercial terms to the business.

One more point worth remembering: users form expectations from how your service actually behaves, not from what you promise. If a service is much more reliable than its target, people start to depend on it as if it never fails, and then suffer when it does. Your real performance is a promise users are quietly relying on.

How to implement SLOs in your organization

A common failure is spending months on theory. Run a short, practical programme instead.

flowchart TD
  A[Week 1: Pick 1 to 3 services<br/>and sponsor] --> B[Week 2: SLO workshop<br/>with dev, product, SRE]
  B --> C[Week 3: Instrument SLIs<br/>and build the SLO dashboard]
  C --> D[Week 4: Run in observe mode<br/>no consequences yet]
  D --> E[Week 5 to 6: Review data,<br/>adjust targets, sign policy]
  E --> F[Week 7+: Burn-rate alerts<br/>and monthly reviews]
  style B fill:#6366f1,color:#fff
  style F fill:#34d399,color:#062

The one-hour SLO workshop (agenda)

1. 5 min: why we are here (show last quarter's incidents and their cost).
2. 15 min: list the top user journeys. Ask the product manager: "If this broke, who would complain first?"
3. 15 min: for each journey, define the SLI as good / valid. Decide where to measure (edge preferred).
4. 10 min: look at the last 4 to 8 weeks of data. Set the initial SLO slightly below current performance.
5. 10 min: agree what happens when the budget is exhausted (the policy).
6. 5 min: assign owners and a review date.

The SLO document (one page, copy this)

Rollout rules that save you pain

• Observe first: run SLOs for 4 weeks with no consequences so teams can trust the data.
• Start loose, tighten later: a target you can meet builds credibility.
• Publish dashboards where product and engineering leaders can see them.
• Make SLOs part of existing rituals: sprint planning, release reviews and incident reviews.
• Review monthly: which budgets burned, why, and what we changed.
• Link to money: translate a burned budget into customer impact and revenue.

Tools you can use

Prometheus plus recording rules (free), Grafana dashboards, OpenSLO or Sloth for SLO-as-code, cloud-native SLO features in your monitoring vendor, or even a spreadsheet for the first month.

Pitfalls

• SLOs that nobody uses in decisions become wallpaper. Put the budget in the release checklist.
• Measuring from inside the service hides outages that the service cannot see.
• Teams gaming the SLI (excluding failures). Review definitions together.
• Setting the same target for everything. A payment API and an internal report generator deserve different numbers.

Interview questions

Q1. Define SLI, SLO and SLA with an example. SLI: the percentage of checkout requests that succeed within 2 seconds. SLO: 99.9% over 30 days. SLA: customers receive a 10% credit if monthly availability falls below 99.5%.

Q2. Why percentiles instead of averages? Averages hide tail latency. If 1% of requests take ten seconds the average barely moves, but real users suffer. Page loads make many requests, so most users eventually hit the tail.

Q3. Rolling window or calendar window? Rolling windows avoid cliff resets and match how people remember outages. Calendar windows align with reporting but encourage gaming. Most SRE teams use rolling 28 or 30 days.

Q4. How do you measure an SLO for a low-traffic service? Use synthetic probes, longer windows or event-count based thresholds, because a single failure out of ten requests would otherwise destroy the SLI.

Q5. A service depends serially on three components at 99.9% each. What is its best possible availability? About 0.999³ ≈ 99.7%. To do better you need redundancy, caching, fallbacks or fewer hard dependencies.

Q6. What should you do when you keep exceeding your SLO by a lot? Treat the spare budget as an opportunity: ship faster, take reasonable risks, simplify costly redundancy, or tighten the SLO only if users genuinely need more.

Next: Error Budgets, Burn Rates and Policy shows how SLOs drive daily decisions.