Skip to main content

> sli,_slo,_&_sla_engineering_governance

SLI, SLO, & SLA Engineering Governance

What is the structural difference between an SLI, an SLO, and an SLA in production systems?

Stack: OBSERVABILITY STACKSenior (L5-L6)protocol

THE SHORT ANSWER

An SLI is what you measure (indicator); an SLO is the internal reliability target you strive for (objective); an SLA is the external legal contract with financial consequences if breached (agreement).

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

The Service Level framework creates mathematical precision around service expectations. SLIs (Service Level Indicators) measure raw performance from the user perspective (e.g., ratio of successful requests < 300ms). SLOs (Service Level Objectives) set the target threshold (e.g., 99.9% of requests over 30 days). SLAs (Service Level Agreements) define customer-facing legal commitments with penalty clauses (e.g., 99.5% uptime or 20% billing credit refund).

2. Appropriate Use Context

Mandatory for any production SaaS, API platform, or distributed microservice architecture serving paying customers.

3. Production Failure Modes

Sales promises a customer five-nines (99.999%) availability in an enterprise SLA, while the underlying cloud architecture uses single-AZ databases that only support 99.5%, resulting in massive contract penalties.

4. Diagnostic Signals & Telemetry

Frequent customer outage complaints while internal monitoring dashboards show green; lack of shared definitions for what constitutes a 'successful' request.

5. Prevention & Safeguards

Ensure SLOs are always stricter than SLAs (e.g., 99.9% SLO vs 99.5% SLA); compute SLIs directly at user-facing edge load balancers, not internal healthy container probes.

6. Architectural Trade-offs

Requires rigorous telemetry instrumentation and legal-engineering alignment in exchange for clear operational targets and protected revenue.

Case Study (TinyCTO In-Field Example)

TinyCTO Episode 16: The API returned HTTP 200 with an internal JSON error body. The monitoring counted it as 100% uptime, but customers were blocked. The team redefined their SLI to inspect payload validity.

Interactive Concept Drills

3 Cards
Q1

What is the relationship formula between SLA, SLO, and SLI?

SLI is the metric; SLO is the internal goal (stricter); SLA is the customer agreement (more lenient).
Q2

Why should an internal SLO be stricter than an external SLA?

To create an early warning buffer that allows engineers to fix issues before contractual financial penalties are triggered.
Q3

Where should user-facing latency SLIs be measured?

At the API gateway or client-side telemetry, capturing actual end-to-end round trip time.

SLI, SLO, & SLA Engineering Governance — Technical FAQ

What should you do if an SLI measurement is inaccurate?

Iterate on the SLI specification immediately; an inaccurate indicator produces misleading error budgets and false confidence.

Who owns the definition of an SLO?

Jointly owned by Product Management (defining user needs) and Engineering/SRE (defining technical feasibility).

How many SLOs should a single service have?

Keep it simple: 2 to 4 critical user-facing SLOs (e.g., availability and p95/p99 latency).

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • SLAs without corresponding internal SLOs are financial liabilities waiting to trigger.
  • Good SLIs measure user happiness, not infrastructure resource consumption.

Common Misconceptions

  • Believing that CPU utilization or memory percentage is an appropriate SLI.

Decision & Governance Guidance

Define SLIs in terms of good requests divided by total valid requests over a rolling evaluation window.

Authoritative Sources & Standards