Definition
- SLI (Service Level Indicator) – A precisely defined, measured quantity reflecting service quality from the user's perspective, such as the percentage of successful requests or requests served faster than a latency threshold.
- SLO (Service Level Objective) – A target value for an SLI over a period, such as 99.9% of requests successful over 30 days, defining what "reliable enough" means.
- Relationship – The SLI is the actual measurement; the SLO is the goal that measurement must meet.
- Error budget – 100% minus the SLO target; the amount of unreliability permitted.
- SLA vs SLO – An SLA is an external contract with penalties; an SLO is an internal target, usually stricter than the SLA.
At the National Bank of India, think of reliability as the punctuality of the branch. The SLI is the actual measurement: "out of every hundred customers this month, how many were served successfully and quickly?" The SLO is the promise the bank sets itself: "at least 99.9 out of every hundred must be served successfully." If the measured number stays at or above the target, the branch is meeting its reliability promise; if it drops below, the branch is failing its own standard and must act.
Understanding the Concepts
What is an SLI?
An SLI is defined as a ratio of good events to total valid events, which keeps it between 0% and 100% and makes it directly comparable to a target. The most common SLIs are availability and latency.
# Availability SLI:
SLI = (successful requests) / (total valid requests) * 100%
# Latency SLI:
SLI = (requests served < 300ms) / (total valid requests) * 100%
# Example for National Bank of India transfer API (30-day window):
# Total requests: 1,000,000
# Successful (2xx): 999,500
# Availability SLI: 999,500 / 1,000,000 = 99.95%
# Measuring availability SLI with Prometheus
# PromQL: success rate over 30 days
sum(rate(http_requests_total{app="transfer-api", status=~"2.."}[30d]))
/
sum(rate(http_requests_total{app="transfer-api"}[30d]))
# Measuring latency SLI: % of requests under 300ms
sum(rate(http_request_duration_seconds_bucket{app="transfer-api", le="0.3"}[30d]))
/
sum(rate(http_request_duration_seconds_count{app="transfer-api"}[30d]))
What is an SLO?
An SLO is a target for an SLI over a defined window. Saying "the availability SLO is 99.9%" means at least 99.9% of valid requests must succeed over the window (typically 28 or 30 rolling days). The choice of target matters enormously.
# Cost of each additional nine:
# SLO Allowed downtime/year Allowed failures/month (1M requests)
# 99% ~3.65 days 10,000 failures
# 99.9% ~8.76 hours 1,000 failures
# 99.99% ~52.6 minutes 100 failures
# 99.999% ~5.26 minutes 10 failures
# National Bank of India transfer API:
# Availability SLO: 99.9% (allows ~1000 failed transfers/month)
# Latency SLO: 99% of requests under 300ms
How do SLI and SLO relate to each other?
The SLI is continuously measured and compared against the SLO to determine whether the service is meeting its reliability goal. This naturally produces an error budget.
# SLI = 99.95% (actual measurement)
# SLO = 99.9% (target)
# Result: SLI > SLO -> meeting the objective, error budget has room
# Error budget = 100% - SLO = 100% - 99.9% = 0.1%
# Over 1,000,000 requests: 0.1% = 1,000 allowed failures
# Actual failures: 500
# Budget consumed: 500 / 1000 = 50%
# Budget remaining: 50% -> safe to ship features
# Grafana dashboard for SLO tracking
# Panel 1: SLI current value (99.95%)
# Panel 2: SLO target line (99.9%)
# Panel 3: Error budget consumed (50%)
# Panel 4: Error budget burn rate (healthy / at risk / critical)
How is an SLO different from an SLA? (comparison table)
| Aspect | SLO | SLA |
|---|---|---|
| Audience | Internal (engineering team) | External (customers, contracts) |
| Consequence of breach | Team freezes features, fixes reliability | Financial penalties, legal consequences |
| Typical target | Stricter (e.g., 99.9%) | Looser (e.g., 99.5%) |
| Purpose | Engineering decision-making tool | Business commitment |
# National Bank of India example:
# Internal SLO: 99.9% availability (the team's target)
# External SLA: 99.5% availability (the customer contract)
# Safety margin: 0.4% -- the team aims higher than the contract requires
# If SLI drops to 99.7%, the SLO is breached but the SLA is still met.
# The team acts before the customer contract is at risk.
How do you choose the right SLO target?
Set the target based on what users actually need and what the business can justify, not at an arbitrary maximum. Chasing unnecessary nines wastes engineering effort that could deliver features.
# Decision framework:
# 1. What do users actually need?
# Transfer API: 99.9% (users expect near-perfect reliability for money)
# Report generation: 99% (users tolerate occasional delays)
# 2. What can the business afford?
# 99.99% requires redundancy, multi-region, on-call 24/7 -> expensive
# 99.9% is achievable with good practices -> reasonable investment
# 3. What do dependencies allow?
# If the payment gateway is 99.95%, you cannot promise 99.99%.
What about alerting on SLO breaches?
Alert on burn rate (how fast the error budget is being consumed) rather than on every transient blip. Multi-window, multi-burn-rate alerts are the standard technique.
# Prometheus alert: fast burn rate (pages immediately)
groups:
- name: slo-alerts
rules:
- alert: TransferAPIHighBurnRate
expr: |
(
1 - (sum(rate(http_requests_total{app="transfer-api",status=~"2.."}[1h]))
/ sum(rate(http_requests_total{app="transfer-api"}[1h])))
) > (14.4 * 0.001) # 14.4x burn rate over 1h
for: 5m
labels:
severity: critical
annotations:
summary: "Transfer API is burning error budget 14x faster than allowed"
# Burn rate alerting:
# Fast burn (1h window, 14.4x rate) -> page immediately (active incident)
# Medium burn (6h window, 6x rate) -> page within 30 minutes
# Slow burn (3d window, 1x rate) -> ticket, no page
What are common mistakes?
# WRONG: Setting the SLO at 100%
# No system is 100% reliable. A 100% SLO means zero error budget,
# so ANY failure breaches the SLO. The team can never ship anything.
# CORRECT: Set the SLO based on user needs, e.g., 99.9%.
# This gives an error budget of 0.1% for deployment risk and experimentation.
# WRONG: Measuring SLI at the server instead of the load balancer
# If the server is down, it reports nothing, so the SLI looks perfect.
# CORRECT: Measure at the load balancer or gateway
# It sees 502/503 responses even when the backend is down.
What are common interview follow-up questions?
- "What if the SLI is above the SLO?" – The service is meeting its objective and there is error budget remaining, so the team can take deployment risk and ship features.
- "What if the SLI drops below the SLO?" – The error budget is exhausted; the team should freeze risky changes and prioritize reliability.
- "Can you have multiple SLIs for one service?" – Yes. A transfer API might have an availability SLI and a latency SLI, each with its own SLO.
Visual Overview
SLI, SLO, Error Budget, and SLA Relationship ============================================== ┌─────────────────────────────────────────────┐ │ 100% │ │ ┌─────────────────────────────────────┐ │ │ │ SLO Target: 99.9% │ │ │ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ │ │ │ SLI (actual): 99.95% ▲ │ │ │ │ │ meeting │ │ │ │ │ SLO │ │ │ └─────────────────────────────────────┘ │ │ Error Budget = 100% - 99.9% = 0.1% │ │ Budget consumed: 50% (500 of 1000 allowed) │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ SLA (external): 99.5% │ │ │ │ Safety margin: 0.4% │ │ │ └─────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ Budget remaining? -> Ship features, take risk Budget exhausted? -> Freeze features, fix reliability
Key Takeaway
A Service Level Indicator is a precisely defined, measured quantity reflecting service quality from the user's perspective, and a Service Level Objective is the target that indicator must meet over a period. The SLI is the actual measurement (the percentage of successful requests, or requests served under 300ms, over 30 days), and the SLO is the goal (99.9% successful). Together they turn reliability from a vague aspiration into a number you can track and act on.
Choosing the SLO target matters because each additional nine is dramatically more expensive: 99.9% allows about 8.7 hours of downtime per year while 99.99% allows only 52 minutes. Set the target based on what users need and what the business can justify, not at an arbitrary maximum. The SLI and SLO naturally produce an error budget (100% minus the SLO), and teams use that budget to decide when to ship features versus when to focus on reliability. At the National Bank of India, the transfer API had a 99.9% availability SLO and a 99% latency SLO, and when the latency SLI breached its target, the team knew precisely to freeze latency-risky changes and fix performance.
Remember one sentence: the SLI is how you are actually doing, the SLO is how well you have decided you must do, and the error budget is the space between them that funds both feature velocity and reliability investment.
---