SLA vs SLO vs SLI: What Is the Difference?
Understand SLI, SLO, and SLA: measured metrics, internal targets, error budgets, and external contracts, with clear examples.
Expected Interview Answer
An SLI (Service Level Indicator) is a measured metric like request latency or error rate, an SLO (Service Level Objective) is the internal target you set for that metric (e.g. 99.9% of requests under 200ms), and an SLA (Service Level Agreement) is the external, often contractual, promise made to customers that usually includes penalties if the SLO-backed target is missed.
These three terms form a hierarchy of increasing formality and consequence. The SLI is raw, observable data collected from the system — availability percentage, latency percentile, or error ratio — and it must be measured accurately before anything else is meaningful. The SLO is the internal reliability target the engineering team commits to hitting, chosen deliberately below 100% because perfect reliability is prohibitively expensive and slows feature velocity; teams track an “error budget,” the allowed amount of unreliability, to balance shipping speed against stability. The SLA takes a subset of SLOs, usually looser than the internal target for safety margin, and turns them into a customer-facing contract with financial or credit-based consequences for breach. Google's SRE practice popularized this distinction specifically so teams stop conflating “what we measure” with “what we promise.”
- Gives engineering teams a measurable, data-driven definition of “reliable enough”
- Error budgets derived from SLOs let teams balance velocity against stability objectively
- Separating internal SLOs from external SLAs provides a safety margin before contractual penalties trigger
- Creates a shared vocabulary between engineering, product, and customer-facing teams
AI Mentor Explanation
The SLI is the raw scoreboard number: the bowler's economy rate this match, just a measured fact. The SLO is the captain's internal target for that bowler — "keep the economy under six an over" — a bar the team aims for that is not shared with anyone outside the dressing room. The SLA is the sponsorship contract clause promising fans a certain over-rate of play, with financial penalties to the broadcaster if the match runs too slow. Each layer adds more formality and more consequence on top of the same underlying measurement.
Step-by-Step Explanation
Step 1
Measure the SLI
Instrument the system to capture a raw, objective metric such as latency, availability, or error rate from real traffic.
Step 2
Set the internal SLO
Pick a target below 100% for that SLI (e.g. 99.9% availability) that the team commits to internally, deriving an error budget from the gap.
Step 3
Draft a safer external SLA
Publish a customer-facing SLA that is looser than the internal SLO, giving a margin before contractual penalties trigger.
Step 4
Monitor and react to budget burn
Track error budget consumption continuously; slow down risky releases when the budget is nearly exhausted, ship faster when it is healthy.
What Interviewer Expects
- Correctly orders the three terms: SLI is measured, SLO is internal target, SLA is external contract
- Explains why SLOs are set below 100% and mentions the error budget concept
- Notes that SLAs are typically looser than SLOs to leave a safety margin
- Gives a concrete example metric (latency, availability, error rate)
Common Mistakes
- Using the three terms interchangeably without distinguishing them
- Setting an SLO target of 100% and not explaining why that is unrealistic
- Forgetting that an SLA usually carries financial or contractual penalties, unlike an SLO
- Not mentioning error budgets as the practical mechanism that ties SLOs to release decisions
Best Answer (HR Friendly)
“Think of it as three layers: the SLI is the actual number we measure, like how often the service is up. The SLO is the internal goal we set for ourselves based on that number, like “be up 99.9% of the time.” The SLA is the promise we make to customers, usually a bit more relaxed than our internal goal, with consequences if we break it.”
Code Example
service: checkout-api
sli:
availability:
query: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
latency_p99:
query: histogram_quantile(0.99, http_request_duration_seconds_bucket)
slo:
availability:
target: 0.999 # internal target: 99.9%
window: 30d
errorBudget: 0.001 # 0.1% allowed unreliability per window
latency_p99:
target: 0.3 # 300ms
window: 30d
sla:
availability:
target: 0.995 # looser than SLO for safety margin
penalty: "10% service credit per 0.1% below target"Follow-up Questions
- How is an error budget calculated from an SLO, and what happens when it is exhausted?
- Why should an SLA target usually be looser than the internal SLO for the same metric?
- How would you choose which SLIs actually matter for a checkout service versus a batch pipeline?
- What is the difference between a multi-window and single-window SLO burn-rate alert?
MCQ Practice
1. Which of the three terms represents a raw, measured metric?
The SLI (Service Level Indicator) is the directly measured metric, such as latency or availability, that SLOs and SLAs are built on top of.
2. Why is an SLA typically set looser than the corresponding internal SLO?
Teams keep the external SLA looser than the internal SLO so that missing the internal target does not automatically trigger a customer-facing contractual breach.
3. What is an error budget derived from?
An error budget is the allowed amount of unreliability, calculated as 100% minus the SLO target, which teams spend on risk like releases and experiments.
Flash Cards
SLI? — A Service Level Indicator: the raw, measured metric such as latency or availability.
SLO? — A Service Level Objective: the internal target set for an SLI, e.g. 99.9% availability.
SLA? — A Service Level Agreement: an external, often contractual promise, usually looser than the SLO.
Error budget? — The allowed amount of unreliability (100% minus the SLO target) that teams spend on releases and risk.