SLO overview

A Service Level Objective (SLO) is a measurable promise about your service's reliability. DevFlow's SLO product is a thin opinionated model on top of your existing monitors.

the model

An SLO has:

• A target — 99.9% for example.
• A window — 28d rolling, typically.
• A good-event definition — what counts as a successful request. Often a response-assertions expression.
• An error budget — the permitted unreliability, derived from target and window.

For a 99.9% SLO over 28 days, the error budget is 28 × 24 × 60 × (1 - 0.999) = ~40 minutes.

creating one

name: payments-availability-99.9
target: 0.999
window: 28d
sli:
  source_monitor: payments-api-charge
  good_event:
    status_in: [200, 201, 204]
    latency_lt_ms: 1000

Or in Terraform — see terraform-provider.

the SLO page

Each SLO has a page that shows:

• SLI — current attainment over the window.
• Burn rate — multiplier on error budget (1.0 means burning budget at the rate that exhausts it exactly at window end).
• Time to depletion — estimate based on current burn rate.
• Recent burn events — windows in the last 14 days where burn rate exceeded 2.0.

alerting on SLOs, not monitors

Alerting on raw monitor failures is loud. Alerting on error budget burn is calm and meaningful. The recommended approach uses two windows — see slo-multi-window-alerting for the canonical Google CRE pattern.

tagging

Every monitor that contributes to an SLO should carry the slo tag matching the SLO name. tagging-strategy documents the convention.