SLO means Service Level Objective — the internal reliability target a team commits to, such as 99.9% of homepage requests returning in under 400ms over a rolling 30-day window. SLOs sit inside the SLA envelope and give engineering the numbers to code, alert,…
SLOs are the operational form of the SLA. Where the SLA promises the customer 99.5% uptime, the internal SLO is usually stricter (99.9%) so there is headroom before contract penalties kick in.
Each SLO has a service level indicator (SLI) that measures it — availability, latency, error rate, freshness. When the SLI drops below the SLO, the error budget shrinks; when it burns out, deploys freeze until reliability is restored.
SLOs replace argument with math. Instead of 'is this outage bad?' the team asks 'did this outage burn our error budget?'. That reframes reliability from vibes to a shared, quantitative constraint — and stops feature velocity from silently degrading uptime.