SLO / SLI
Service Level Objective: a target reliability (e.g. 99.9% of requests < 500ms) measured by an SLI (a metric). SLOs drive alerting and error budgets, aligning engineering on user-visible reliability instead of raw uptime.
- Any user-facing service.
- Aligning teams on reliability vs velocity.
- Internal services without user impact.
- Without the metrics to measure them.
Definition
An SLI is a measured indicator of service quality (e.g. success rate, latency p99). An SLO is a target for that SLI over a window. The error budget is 1 - SLO; when it's consumed, you slow features and fix reliability.
Why it exists
'100% uptime' is impossible and unhelpful. SLOs quantify what users actually care about, set a shared reliability target, and give an error budget that balances feature velocity against reliability.
How it works
Define SLIs from metrics (success rate, latency). Set SLOs (e.g. 99.9% over 28 days). Track error budget burn rate; alert on fast burn so you react before users are meaningfully affected. Multi-window burn-rate alerting reduces noise.
Scaling limits
Choosing the right SLIs and targets is hard and political. Too-loose SLOs miss real pain; too-tight ones waste effort. SLOs need good metrics and a culture of enforcement.
Cost shape
Cheap to define; the cost is the discipline to stop shipping when the budget is spent.
Alternatives
- Uptime % — Simpler but ignores latency and partial failures.
- No targets — No alignment, reactive ops.
Failure modes
- Gaming the SLI (e.g. excluding errors).
- SLOs set without error-budget enforcement.
- Alerting on raw thresholds instead of burn rate.