11.4Defining SLOs

An SLO pairs an SLI with a target and a time window:

# slo-definitions.yaml
service: checkout-api

slos:
  - name: availability
    sli: successful_requests / total_requests
    # "successful" = status code < 500 (client errors are not server failures)
    target: 99.95%
    window: 30d
    error_budget: 0.05%    # ~21.6 minutes of downtime per month

  - name: latency
    sli: requests_completed_under_500ms / total_requests
    target: 99.0%
    window: 30d
    error_budget: 1.0%
    # 1% of requests can exceed 500ms without breaching the SLO

  - name: correctness
    sli: orders_with_correct_total / total_orders
    target: 99.99%
    window: 30d
    error_budget: 0.01%

SLO Design Guidelines

1. Start with user expectations. If your users expect checkout to take under 2 seconds, your latency SLO should be stricter than that.
2. Use percentiles, not averages. p99 or p95 latency SLOs protect the tail of the distribution.
3. Use rolling windows. A 30-day rolling window is standard. Calendar months create end-of-month panic.
4. Do not aim for 100%. A 100% SLO means zero tolerance for any failure, which halts all development. Even Google targets 99.99%, not 100%.
5. Fewer is better. 3-5 SLOs per service is enough. Too many SLOs create confusion about priorities.