Photo by Vitaly Gariev on Unsplash

SLI, SLO, SLA and the Reliability Metrics That Keep Production Systems Alive

A practical guide to availability, error budgets, and incident response for engineers and SREs

🚨 Every engineer who has been on-call has lived through this: the alert fires at 2am, the system is down, and nobody agrees on how bad it is or how fast they need to fix it.

The teams that recover fastest aren’t just technically sharper — they share a common language before the incident happens. That language is built on eight reliability metrics.

Here they are, explained clearly with real examples.

The Hierarchy: SLI → SLO → SLA

Before diving in, understand how these three relate to each other:

+---------------------------+
|  SLI  Service Level       |  <-- What you MEASURE
|       Indicator           |      (e.g. 99.5% uptime this minute)
+---------------------------+
            |
            | drives
            v
+---------------------------+
|  SLO  Service Level       |  <-- What you TARGET internally
|       Objective           |      (e.g. must stay above 99.9%)
+---------------------------+
            |
            | sets ceiling for
            v
+---------------------------+
|  SLA  Service Level       |  <-- What you PROMISE externally
|       Agreement           |      (e.g. guarantee 99.5% or refund)
+---------------------------+

⚠️ The golden rule: SLA < SLO < what you actually achieve. Always leave a buffer, or you will be writing apology emails.

📊 SLI — Service Level Indicator

The actual measurement — a specific metric you track in real time.

• Availability → (successful requests / total requests) × 100
• Error rate → (5xx errors / total requests) × 100
• Latency p99 → 99% of requests complete under X ms
• Throughput → requests processed per second

Example:

Total requests:    10,000
Failed requests:       50

Availability SLI = (9950 / 10000) × 100 = 99.5%
Error rate SLI   = (50 / 10000) × 100   = 0.5%
p99 latency SLI  = 450ms

The SLI is just the measurement. It has no opinion. It tells you exactly where you are right now.

🎯 SLO — Service Level Objective

Your internal target — the line your team commits to not crossing. Always stricter than the SLA to provide a safety buffer.

Examples:
  "Availability SLI must stay above 99.9%"
  "p99 latency SLI must stay below 500ms"
  "Error rate SLI must stay below 0.1%"

The Error Budget — the most powerful concept in SRE

The error budget is the allowable amount of unreliability you can consume before breaching your SLO.

SLO = 99.9% availability over 30 days

Total minutes in 30 days = 43,200
Allowed downtime (0.1%)  = 43.2 minutes  <- this is your error budget

Now imagine you have used 40 of those 43.2 minutes this month:

Error Budget - 30 days (total allowance: 43.2 min)

[##########################################################....]
 ^                                                         ^
 Used: 40 min (93%)                        Remaining: 3.2 min (7%)

  Status: CRITICAL - nearly exhausted, freeze risky deployments!

This single concept resolves the age-old tension between developers (move fast) and operations (stay stable). When the error budget is healthy, ship features. When it is almost gone, freeze risky deploys and focus on reliability. It is just math — not politics.

🤝 SLA — Service Level Agreement

The contractual promise to your customers — with financial consequences if broken.

SLO (internal):  "We target 99.9% uptime"
SLA (external):  "We guarantee 99.5% uptime or you receive a credit"

Real-world examples from major cloud providers:

• AWS EKS (Control plane) → 99.95% SLA → Service credits on breach
• AWS EC2 (Single instance) → 99.5% SLA → 10–30% credit on breach
• AWS RDS (Multi-AZ) → 99.95% SLA → Service credits on breach
• GCP GKE (Control plane) → 99.95% SLA → Credits on breach

Notice that AWS sets their SLA at 99.95% — but internally their SLO is much higher. The gap between SLA and SLO is their buffer.

📐SLI, SLO, and SLA work together in practice

[Customer signs SLA: 99.5% uptime guaranteed]
            |
            v
[Engineering sets SLO: 99.9% target]  <-- buffer above SLA
            |
            v
[Monitoring tracks SLI every minute] <----------+
            |                                    |
            v                                    |
     SLI near SLO? ------- NO -------------------+
            |
           YES
            |
            v
    [ALERT fires - on-call paged]
            |
            v
       [Fix incident]
            |
            v
      SLO breached? --- NO ---> [SLA safe, no penalties]
            |
           YES
            |
            v
    [SLA breached - credits owed to customer]

When this flow is working correctly, your SLA is never breached — because your SLO catches problems first.

The Four MTTX Metrics

These four metrics measure your incident lifecycle end-to-end.

⏱️ MTTF — Mean Time To Failure

How long does the system run before something breaks?

Disk fails on average every 3 years
MTTF = 3 years

Higher MTTF = more stable, more durable system. Improved by redundancy, testing, and chaos engineering.

🔍 MTTD — Mean Time To Detect

How long from failure occurring to your team being alerted?

System failed at 02:00
Alert fired   at 02:05
MTTD = 5 minutes

Lower MTTD = problems caught faster. Improved by better monitoring, synthetic probes, and lower alert thresholds. A 5-minute MTTD means 5 minutes of silent failure every incident — multiply that by 50 incidents a year and you have 4+ hours of invisible outage.

🛠️ MTTR — Mean Time To Repair

How long from alert to full recovery?

Incident 1: 30 min to fix
Incident 2: 60 min to fix
Incident 3: 90 min to fix

MTTR = (30 + 60 + 90) / 3 = 60 minutes

Lower MTTR = faster recovery. Improved by runbooks, on-call automation, and observability tooling. This is the metric your customers feel most directly.

📅 MTBF — Mean Time Between Failures

How often does the system fail on average?

Incident on Jan 1 -> resolved -> next incident on Jan 15
MTBF = 14 days

Higher MTBF = fewer incidents. MTBF = MTTF + MTTR.

How All Four Metrics Connect

⏱️ MTTF → 🚨 MTTD → 🔧 MTTR → 📅 MTBF

  +----------------+  MTTF   +----------+  MTTD  +---------+
  | System Running |-------->| FAILURE  |------->|  ALERT  |
  |   (green)      |         |  (red)   |        | (amber) |
  +----------------+         +----------+        +---------+
          ^                                            |
          |                                      MTTR  |
          |                                            v
          |                               +------------------+
          +-------- next MTTF ----------- | System Restored  |
                                          |    (green)       |
                                          +------------------+

  MTBF = MTTF + MTTR
  Availability = MTTF / (MTTF + MTTR)

Example:

MTTF = 14 days = 20,160 min
MTTR = 60 min

Availability = 20,160 / (20,160 + 60) = 99.7%

9️⃣ The “Nines” — What Uptime Actually Means in Human Time

“99% uptime” sounds great. Until you do the math.

🟥 99% → 3.65 days downtime/year → Dev and test environments
🟧 99.9% → 8.7 hours downtime/year → Internal tools, low-traffic apps
🟨 99.95% → 4.4 hours downtime/year → Standard SaaS products
🟩 99.99% → 52 minutes downtime/year → E-commerce, customer-facing APIs
💚 99.999% → 5.2 minutes downtime/year → Payments, telecom, critical infra

Visualized as annual downtime in minutes:

🔴 99%     | ############################################## 5256 min
🟠 99.9%   | ######                                         526 min
🟡 99.95%  | ###                                            263 min
🟢 99.99%  | #                                               52 min
💚 99.999% | .                                                5 min

Going from 99% to 99.9% sounds like “just 0.9% better.”

It is the difference between 3.6 days and 8.7 hours of downtime per year. Your customers notice.

💰 Cost vs Reliability: Pick Your Strategy

Not every service needs five nines. Choose based on business impact:

• 🧊 Cold Backup → lowest cost, RTO ~4 hours → dev tools, internal systems
• 🕯️Pilot Light + Velero → moderate cost, RTO ~30 min → standard SaaS
• ♨️ Warm Standby → higher cost, RTO ~5 min → e-commerce, customer APIs
• 🔥Active-Active Multi-Region → highest cost, RTO ~0 → payments, banking

🧩 Putting It All Together — A Real Example

☸️ Here is what a healthy month looks like on a production Kubernetes cluster :

📊 SLI:  measured availability = 99.92% this month. ✅ above SLO

🎯 SLO:  internal target = 99.9%
      SLI (99.92%) > SLO (99.9%)
      Error budget remaining = ✅ on track — 28 min budget left

🤝 SLA:  customer promise = 99.5%
      SLI (99.92%) >> SLA (99.5%) -> ✅ no breach, no credits owed

🚨 MTTD: alerts fire within 3 min on average  ✅ fast detection
🔧 MTTR: last 3 incidents = 15, 20, 25 min -> MTTR = 20 min ✅ good recovery
📅 MTBF: incidents Jan 1, Jan 15, Feb 3   -> avg 16 days between failures ✅ stable system

The error budget has 28 minutes remaining with a week left in the month — safe to continue shipping features.

⚡📌 Quick Reference

• SLI → What is the current measurement? → Track it
• SLO → What is our internal target? → Set higher than SLA
• SLA → What did we promise the customer? → Set lower than SLO
• MTTR → How fast do we recover? → Lower is better
• MTBF → How often do we fail? → Higher is better
• MTTD → How fast do we detect failure? → Lower is better
• MTTF → How long until something breaks? → Higher is better
• Error Budget → How much unreliability remains? → Guard it carefully

💡 The Real Insight

These aren’t just metrics. They are a shared contract between engineering, product, and business.

• Without SLOs → every outage becomes a political fight about blame and priorities.
• With SLOs → it is just math. Objective, calm, and actionable.

The best on-call engineers I have worked with don’t panic during incidents. They check the error budget, assess the MTTD, and execute — because they have already agreed, before the incident, on what “good enough” looks like.

🤔 What reliability metric does your team track most obsessively?

👇Drop it in the comments.