SLO Definition Framework

A service level objective states how reliable a service should be, measured from the user's perspective. This framework turns vague reliability aspirations into a small number of numeric targets that engineering, product and operations can all reason about.

How it works

Each SLO has three parts: an indicator (SLI), a target and a window. The SLI is a ratio of good events to valid events, such as requests answered successfully within 300 ms. The target is the fraction that must be good, and the window is how long the fraction is measured. The error budget is one minus the target: a 99.9 percent target over 28 days allows roughly 40 minutes of total failure.

Adoption usually goes best when the first SLOs are modest and visible. Pick two or three services whose owners are enthusiastic, publish the targets on a shared dashboard and let the first budget review be a learning exercise rather than an audit. As confidence grows, extend to dependencies by agreeing internal SLOs between teams, so that a platform team knows what its consumers expect and consumers know what they can rely on when setting their own targets.

Implementation steps

1. List critical user journeys, such as checkout or login, and choose one or two per service.
2. Pick an indicator category: availability, latency, correctness or freshness.
3. Measure as close to the user as practical, at the load balancer or in the client, not only inside the service.
4. Set an initial target using historical data, then choose something slightly below current performance.
5. Write an error budget policy: what slows down or stops when the budget is exhausted, and who decides.
6. Build burn-rate alerts instead of raw threshold alerts.
7. Review budget consumption in a recurring meeting and adjust targets quarterly.

Pitfalls

• Setting 99.99 percent because it sounds good, when dependencies cannot support it.
• Counting health-check traffic or bot traffic as valid events.
• Defining SLOs per component rather than per user journey.
• Having a budget policy nobody enforces, which turns SLOs into decoration.
• Using averages for latency instead of percentiles or threshold ratios.

Metrics to watch

• Error budget remaining and its burn rate over one hour and six hours.
• Number of budget exhaustions per quarter per service.
• Percentage of production services with an approved SLO.
• Alerts that page without a corresponding SLO burn.
• Ratio of SLO-driven work items to total reliability work.

Example SLO specification

service: checkout-api
slos:
  - name: availability
    sli:
      good: http_requests_total{status!~"5.."}
      total: http_requests_total
    target: 0.999
    window: 28d
  - name: latency
    sli:
      good: http_request_duration_bucket{le="0.3"}
      total: http_request_duration_count
    target: 0.95
    window: 28d
alerts:
  - burn_rate: 14.4
    window: 1h
    severity: page
  - burn_rate: 6
    window: 6h
    severity: page
  - burn_rate: 1
    window: 3d
    severity: ticket

Key takeaways

• Measure user-visible outcomes, not internal resource health.
• The error budget is the mechanism that makes SLOs change decisions.
• Start with few SLOs, and tighten only when the data supports it.
• Alert on budget burn rate to cut noise and catch real problems early.