Service Level Objectives (SLOs) are the quantifiable targets your service commits to maintaining. They answer: “How reliable should our service be, and how do we know if we’re meeting that target?”
SLOs are built on two foundational concepts:
Traditionally, operations asked: “Is the system up or down?” This worked for monolithic systems.
Modern systems need:
| Problem | Solution |
|---|---|
| No clarity on reliability target | SLOs define explicit targets based on business impact |
| Uncertain deployment risk | Error budgets make risk explicit |
| No shared language with business | SLOs provide quantifiable metrics (99.9% = 43 min downtime/month) |
| Burnout from constant alerts | SLOs guide what’s critical enough to page on |
| No framework for stabilize vs. deploy | Error budgets show available budget for changes |
An SLI is a specific, measurable metric that represents what users care about.
Users don’t care about infrastructure metrics. They care about:
Formula:
SLI = (good_events) / (total_events)
Example (API Availability):
SLI = (2xx/3xx responses) / (total requests)
= 995,000 / 1,000,000 = 99.5%Examples:
Web API:
Good Event: Request returns 2xx/3xx in < 30 seconds
Bad Event: Request returns 5xx OR times out (> 30s)
SLI = Successful requests / Total requestsDatabase:
Good Event: Query completes in < 100ms, returns correct data
Bad Event: Query times out (> 100ms) OR returns wrong data
SLI = (queries_correct_and_fast) / (total_queries)Batch Processing:
Good Event: Job completes within 1 hour
Bad Event: Job takes > 1 hour OR fails
SLI = (jobs_completed_on_time) / (total_jobs)An SLO is a target you set for an SLI.
SLO = SLI + Target + Time Window
Example: “99.9% of API requests succeed, measured monthly”
Components:
| Without SLOs | With SLOs |
| – Reliability decisions are arbitrary – No shared expectations – Can’t discuss reliability vs. cost trade-offs | – Explicit targets everyone agrees on – Data-driven deployment decisions – Quantifiable business metric |
Example: Choosing an SLO
Service: Authentication API
Criticality: Critical (blocks all user access)
Candidate SLOs:
├─ 99% (3.65 days downtime/year)
│ └─ Too much; users locked out for days
│
├─ 99.9% (8.76 hours downtime/year)
│ └─ Acceptable but risky; users wait hours for retry
│
├─ 99.99% (52 min downtime/year)
│ └─ ✓ Good target; very rare outages
│ └─ Cost: High (redundancy, multi-region)
│
└─ 99.999% (5 min downtime/year)
└─ Overkill; cost not justified
DECISION: 99.99%
RATIONALE: Auth is critical; cost is justifiedAn SLA is a legal contract with customers about availability, often with financial penalties.
SLO (Internal Target): 99.95%
↓
SLA (Customer Promise): 99.9%
↓
Buffer: 0.05%
If you hit 99.9%, SLA is met ✓
If you hit 99.85%, SLA is breached ✗ (credits owed)Key insight: SLOs > SLAs (internal targets > customer promises)
Example
AWS SLA (Public): 99.95% availability
AWS SLO (Internal): 99.99% availability
This buffer lets AWS do:
An error budget is the amount of downtime you can tolerate while still meeting your SLO.
Formula
Error Budget = (1 - SLO%) × Total Time in Period
Example (99.9% SLO for 30 days):
= (1 - 0.999) × 30 × 24 × 60 minutes
= 0.001 × 43,200 minutes
= 43.2 minutes per monthError budget transforms SLOs from abstract to operational. Lets take a case with and without error budgets.
Without error budget:
With error budget:
E-commerce Checkout Service
SLO = 99.95% Availability, which allows approximately 21.6 minutes of downtime per month.
Most of the error budget has been consumed. The team should prioritize reliability improvements and be cautious with future deployments until service stability improves.