Definition
- SLI is a precisely measured ratio of good events to total valid events
- SLO is an internal target for that SLI over a rolling window, like 99.95% over 28 days
- SLA is an external contract with customers specifying consequences when the promise is broken
- The gap between the stricter SLO and the looser SLA is the safety cushion
- Error budget, alerting, and feature-vs-reliability decisions all flow from the SLO
At the National Bank of India, the SLI is the actual measured number: out of every thousand transfers Rajesh and Priya attempt, how many succeed. The SLO is the bank's internal promise: keep that at 99.95% or better. The SLA is the contract with a corporate client: we guarantee 99.9%, and below that we refund fees. The 0.05% gap is the safety cushion.
Understanding the Concepts
What is an SLI?
An SLI is a ratio of good events to total valid events, expressed as a percentage. You define it carefully: which responses count as good, what counts as a valid request, and where you measure.
# Availability SLI in Prometheus
sum(rate(http_server_requests_seconds_count{status!~"5.."}[28d]))
/
sum(rate(http_server_requests_seconds_count[28d]))
# Latency SLI: fraction of requests under 300ms
sum(rate(http_server_requests_seconds_bucket{le="0.3"}[28d]))
/
sum(rate(http_server_requests_seconds_count[28d]))
What is an SLO?
An SLO is a target on that SLI over a rolling window. It is the most important reliability number a team owns.
# SLO: 99.95% success over 28 days
# Total requests: 10,000,000
# Allowed failures (error budget): 5,000
# If failures > 5,000, pause feature work and fix reliability
What is an SLA?
An SLA is an external contract with financial consequences. You never set it equal to the SLO.
# SLA: 99.9% monthly availability
# Penalty: < 99.9% = 10% credit, < 99.0% = 25% credit
# SLO buffer: 99.95% - 99.9% = 0.05% safety cushion
How do SLI, SLO, and SLA relate? (comparison table)
| Aspect | SLI | SLO | SLA |
|---|---|---|---|
| What | Measurement | Internal target | External contract |
| Set by | Engineers | Eng + product | Business + legal |
| Audience | Team | Team | Customers |
| On miss | Investigate | Pause features | Financial penalty |
| Example | 99.93% | Target 99.95% | Promise 99.9% |
SLI (measure) -> SLO (internal goal) -> SLA (external promise)
99.93% 99.95% 99.9%
(team alarm) (contract breach)
How do you choose the right SLI?
A badly defined SLI hides problems. Averages mask the slow tail. Use ratio-based SLIs.
# WRONG: Average latency = 50ms (hides 1% at 5 seconds)
# CORRECT: Ratio SLI = requests under 300ms / total requests
How do you pick the right SLO target?
Pick based on what users need, not aspirational 100%. Each additional nine costs exponentially more.
# Cost of nines (downtime per month):
# 99% = 7.2 hours (cheap)
# 99.9% = 43 minutes (moderate)
# 99.95% = 22 minutes (expensive)
# 99.99% = 4.3 minutes (very expensive)
What are common mistakes?
Setting the SLO equal to the SLA leaves no buffer. Having 15 SLOs per service dilutes focus.
# WRONG: SLO = SLA = 99.9% (no safety buffer)
# CORRECT: SLO = 99.95%, SLA = 99.9% (0.05% buffer)
# WRONG: 15 SLOs per service
# CORRECT: 2-3 SLOs covering availability and latency
What should a senior engineer know?
Have only a handful of SLOs per service. Each SLO should be owned, reviewed, and reported. The SLO drives error-budget burn-rate alerts.
# Sloth SLO config for NBI transfer service
spec:
slos:
- name: availability
objective: 99.95
sli:
events:
error_query: sum(rate(http_requests{status=~"5.."}[{{.window}}]))
total_query: sum(rate(http_requests[{{.window}}]))
What are common interview follow-up questions?
- Should internal services have SLAs? Usually no, but they should have SLOs.
- Why not target 100%? It is impossibly expensive and users cannot perceive the difference.
- What flows from the SLO? The error budget, alerting thresholds, and feature-vs-reliability decisions.
Visual Overview
SLI -> SLO -> SLA Progression
┌──────────┐ ┌──────────┐ ┌──────────┐
│ SLI │───▶│ SLO │───▶│ SLA │
│ Measured │ │ Internal │ │ External │
│ 99.93% │ │ 99.95% │ │ 99.9% │
│ │ │ (alarm) │ │ (penalty)│
└──────────┘ └──────────┘ └──────────┘
▲ │
│ ▼
┌──────────┐ ┌──────────┐
│ Prometh. │ │ Error │
│ metrics │ │ Budget │
└──────────┘ └──────────┘
Key Takeaway
An SLI is a precisely measured ratio of good events to total valid events. An SLO is an internal target set on that indicator over a rolling window. An SLA is an external contract with penalties. The relationship is a clean progression: you measure with SLIs, hold yourself to a stricter SLO, and promise customers a looser SLA.
The gap between the SLO and the SLA is the safety cushion. When the SLI drops below the SLO, the team is alarmed and reacting, but if it is still above the SLA there is no contract breach. This buffer absorbs bad weeks before they become broken contracts.
In the National Bank of India project, the transfer service measured its SLI as the fraction of successful transfers for customers like Rajesh and Priya. The internal SLO was 99.95% and the external SLA was 99.9%. When a degradation pushed the SLI to 99.92%, the team was alarmed and reacting, but still above the SLA, so no penalty was triggered.
Remember one sentence: you measure with SLIs, hold yourself to a stricter internal SLO, and promise customers a looser SLA, and the gap between them is the safety cushion.
---