SLI, SLO, and SLA

What are SLIs, SLOs, and SLAs?

SLI, SLO, and SLA are the three-layer reliability framework from Site Reliability Engineering (SRE). They provide a structured, measurable way to define and manage service reliability.

SLI (Service Level Indicator)

An SLI is a carefully defined quantitative measure of some aspect of the level of service provided. It's what you actually measure.

Examples:

• Availability: percentage of requests that return a successful response
• Latency: percentage of requests completing in < 200ms
• Error rate: percentage of requests returning 5xx errors
• Throughput: requests per second the system processes
• Durability: percentage of data retained without loss (for storage)

SLI (availability) = successful_requests / total_requests × 100%
SLI (latency) = requests_under_200ms / total_requests × 100%

Good SLIs are:

• Measurable from the user's perspective (not just internal metrics)
• Directly correlated with user experience
• Resistant to gaming (hard to make look good without actually being good)

SLO (Service Level Objective)

An SLO is a target value or range for an SLI. It defines "what good looks like" for your service.

Examples:

• Availability SLO: 99.9% of requests succeed
• Latency SLO: 95% of requests complete in < 200ms
• Error rate SLO: < 0.1% of requests return errors

SLOs are internal targets - not contractual commitments. You own them.

Choosing SLO Targets

• Don't aim for 100% - it's neither achievable nor necessary
• Set targets based on what users actually need
• 99.9% availability = 8.77 hours downtime/year
• 99.99% availability = 52.6 minutes downtime/year
• Each extra nine costs significantly more in infrastructure and engineering

Error Budget

Error budget = 1 - SLO. If SLO is 99.9% availability, error budget is 0.1%:

Monthly error budget = 0.1% × (30 days × 24 hours × 60 min × 60 sec)
                     = 0.001 × 2,592,000 seconds
                     = 2,592 seconds (43 minutes) per month

What the error budget enables:

• If budget is healthy (plenty remaining): deploy freely, ship features
• If budget is nearly exhausted: freeze risky deployments, prioritise reliability work
• If budget is exhausted: SRE team can block new feature releases until reliability is restored

The error budget makes the reliability discussion objective - not "do we have enough reliability" but "do we have budget remaining".

SLA (Service Level Agreement)

An SLA is a contractual commitment between a service provider and customers, with defined consequences (financial compensation, service credits) if the SLO is not met.

• SLAs are negotiated with legal teams
• SLA targets are always weaker than internal SLOs (you set SLO at 99.95% but commit to SLA of 99.9%)
• The gap between SLO and SLA is your buffer - you alert on SLO breach before it becomes an SLA breach

Examples:

• AWS EC2 SLA: 99.99% uptime; if < 99.9%, 10% service credit
• Stripe SLA: 99.99% uptime for API

SLI -> SLO -> SLA Relationship

Measure -> SLI (what we observe)
Target  -> SLO (what we aim for, internal)
Contractual -> SLA (what we promise, external)

SLA <= SLO <= ideal (never promise more than you can deliver)

Interview Angle

For SRE or platform engineering roles: articulate the difference between SLI (measurement), SLO (target), SLA (contract). Then explain error budgets - they're the key insight that makes this framework actionable. The error budget bridges reliability and feature velocity: "we have 43 minutes of error budget this month; 10 minutes used; we can proceed with the risky migration."