SLO
A Service-Level Objective is a target reliability metric for a service — typically expressed as a percentage over a time window. For example: 99.9% of API requests return successfully within 200ms over a rolling 30-day window. SLOs are the operational target; the matching SLA is the customer contract (usually looser than the SLO).
SLOs sit between SLIs (the raw measurement, e.g., 'this percentile latency') and SLAs (the contract). A team's SLO is the target it's privately holding itself to; the gap between SLO and SLA is the error budget — the allowed reliability headroom. Setting SLOs too high makes engineering work conservative; too low frustrates customers. The Google SRE handbook is the canonical reference.
Long-form posts that explore slo in depth — when to use it, common failure modes, how AI helps.
- The connected delivery graph: one source of truth from PRD to prodMost teams ship software with five tools that don't talk to each other. The friction isn't any individual tool — it's the missing graph between them. This is the case for one connected graph.9 min read
- What's the actual ROI of AI in software delivery?$4-$8 back for every dollar spent within 6 months, for most teams. The honest math from real data, not the deck.7 min read
Related terms
- Error budget
An error budget is the allowable reliability gap between the SLA (customer contract) and the SLO (operational target).
- MTTR
Mean Time To Recovery is the average elapsed time between an incident's detection and its resolution.
- DORA metrics
The four DORA metrics measure software-delivery performance: deployment frequency, lead time for changes, mean time to recovery (MTTR), and change-failure rate.