SLO vs SLA vs SLI
In Site Reliability Engineering (SRE), defining and measuring reliability is critical. SLIs, SLOs, and SLAs form a hierarchy of metrics and agreements that align engineering, business, and customers on what acceptable reliability looks like.
SLI (Service Level Indicator)
The Measurement
Strengths
- •Objective and quantifiable
- •Reflects actual user experience
- •Based on raw metrics (e.g., latency, error rate, throughput)
Weaknesses
- •Can be noisy if not chosen carefully
- •Difficult to measure accurately from the client perspective
Best For:
Measuring exactly how the system is behaving right now.
SLO (Service Level Objective)
The Goal
Strengths
- •Sets a clear, internal target for reliability (e.g., 99.9%)
- •Drives engineering decisions and error budget policies
- •Balances reliability with feature velocity
Weaknesses
- •Requires organizational buy-in to enforce (e.g., stopping features when missed)
- •Setting the right target is mathematically and politically complex
Best For:
Internal alignment between product and engineering teams.
SLA (Service Level Agreement)
The Contract
Strengths
- •Provides financial guarantees to customers
- •Clearly defines penalties for non-compliance
- •Managed by business and legal teams
Weaknesses
- •Conservative (usually lower than SLOs to avoid payouts)
- •Lags behind actual user pain (a breach means catastrophic failure)
Best For:
External customer contracts and financial risk management.
Feature Comparison
| Aspect | SLI (Service Level Indicator) | SLO (Service Level Objective) | SLA (Service Level Agreement) |
|---|---|---|---|
| Definition | A quantifiable measure of service reliability | An internal target value for an SLI | A business contract with consequences |
| Audience | Engineers | Product & Engineering | Customers, Legal, Business |
| Example | 99.95% of HTTP GET requests in the last 30d succeeded | We aim for 99.9% success rate over 30d | If success rate drops below 99.5%, we refund 10% |
| Consequence of Missing | None directly, just data | Burn error budget, halt feature work | Financial penalties, refunds, lost trust |
| Strictness | N/A (Just a metric) | Strict (Aspirational but required) | Loose (Conservative to avoid payout) |
| Formulated By | Engineering | SRE + Product Management | Business + Legal |
Architecture Rule of Thumb
Always link SLOs directly to actionable Error Budgets. An SLO without an error budget is just an aspirational target. When the budget is exhausted, deployments freeze to prioritize reliability work. Additionally, internal SLO targets must always be stricter than external legal SLAs to prevent costly breaches.
Common Mistakes
- •Using SLI and SLO interchangeably.
- •Setting SLOs to 100% (impossible and counterproductive).
- •Thinking engineering teams define the SLA without business/legal input.
Related Topics
That's where we come in.
Being able to explain when you would choose SLI (Service Level Indicator) or SLO (Service Level Objective) or SLA (Service Level Agreement) is different from reading a comparison table.
Kernelry helps you rehearse technical questions, evidence-led debugging, safe next steps, and the clear communication teams expect. The drills adapt to your answer, so you practice the reasoning rather than memorize a company-specific script. During early access, free accounts include ten daily scenarios across our mixed question pool, with no credit card required.