SLO (Service Level Objective)

An SLO — service level objective — is a target reliability level for a service, measured over a defined period. It answers: how reliable does this service need to be for our users and business?

SLOs are built on SLIs (the indicators you measure) and imply an error budget — the amount of unreliability you can afford before you must slow feature work and focus on stability. When an incident burns through that budget, response urgency rises.

Why it matters

Without SLOs, every blip feels like a crisis and every crisis feels arbitrary. SLOs give engineering and product a shared language: a Sev-2 incident might mean “we are consuming error budget faster than planned,” while a Sev-1 means “we are out of budget now.” That framing connects operational work to structured incident management priorities instead of gut feel.

Example

You define an SLI as successful API requests divided by total requests. Your SLO: 99.9% success over 30 days — roughly 43 minutes of downtime budget per month. A 20-minute outage consumes nearly half the budget; the team schedules a review and defers risky deploys until reliability recovers.

Common mistakes

• Copying vendor “five nines” without tying targets to actual user expectations or cost.
• SLOs on metrics users never feel — CPU usage is not a substitute for request success or latency.
• No escalation when budget is exhausted — an SLO without consequences is just a dashboard decoration.
• Confusing SLO with SLA — SLAs are contractual promises to customers; SLOs are internal targets that should be stricter than what you promise externally.

Pair SLOs with incident metrics like MTTR and MTTD to see whether you are failing because you detect late, recover slowly, or both. Good SLOs make tradeoffs explicit so incidents drive the right conversations.