QuickstartDefine your first SLO

Define your first SLO

Attach a service level objective to a metric and read the error budget.

A Service Level Objective (SLO) wraps an existing metric in a target: a percentage of a rolling window during which the metric must report healthy. The gap between the target and the actual healthy time is tracked as an error budget. When the metric reports unhealthy, the budget burns. When it recovers, the burn stops. The budget surfaces on status pages and in webhook events.

Prerequisites

Steps

Create a service

Services group related SLOs and render as a row on status pages. In the console, open Services, then New service. Name it after the system the SLOs describe, for example checkout-api. The description field is optional.

Define the SLO

Open the service, then SLOs, then New SLO.

Configure:

  • Metric: the metric defined in the previous quickstart page.
  • Target: percentage of the window the metric must remain healthy. A common starting value is 99.9.
  • Window: rolling window in days. A common starting value is 30.
  • Public: enables rendering on customer-facing status pages.

Save the SLO.

Choosing a target

The right target depends on the system's achieved availability over the prior 90 days. If that data is not available, start with 99.5% and tighten once the SLO has accumulated a few weeks of history. A target tighter than reality burns budget on noise and loses signal value.

Read the burn timeline

Open the SLO. The detail page reports:

  • Error budget remaining: percent of the window's allowance still available. At 99.9% / 30 days, the allowance is roughly 43 minutes. Below 100% indicates the metric has been unhealthy for some of the window.
  • Latest burn event: the current or most recent unhealthy stretch, including its start, end (or marker indicating still open), and percent of the budget burned.
  • History: prior burn events in the window, with duration and budget cost.

The evaluator runs every 5 minutes. If the metric flipped to unhealthy during the previous quickstart page, a burn event is visible here.

Subscribe to webhook events

If the organisation's plan includes outbound webhooks, open Webhooks, then New subscription. The events relevant to SLOs are:

  • slo.burn_started: an SLO crossed below its target. The payload includes the slo_id, service_id, started_at, and the current error_budget_burned_pct.
  • slo.burn_resolved: the SLO recovered. The payload includes the matching burn_event_id and the final_budget_remaining_pct.

Wire deliveries to PagerDuty, Slack, or any HTTPS endpoint that accepts JSON. Endpoint quotas vary by plan.

Calculation

Each evaluator tick reads the metric's last status, updates the moving window, and recomputes:

good_samples         = samples that count as healthy, within the window
total_samples        = all samples, within the window
budget_total         = total_samples * (1 - target / 100)
budget_burned        = total_samples - good_samples
budget_remaining_pct = 100 * (1 - budget_burned / budget_total)

The window never reaches back before the SLO was created, so deleting and recreating an SLO resets its epoch.

Every non-healthy sample burns budget. degraded and no_data samples both count against the allowance, not just unhealthy. A no_data sample counts as good only when the metric's no-data treatment folds it to healthy.

A window with no samples at all is governed by the SLO's unknown-data policy, and under the default policy (down) it burns too. Silence is not free. See SLOs and error budgets for the other two policies.

The budget reads collecting rather than a number until the SLO has 24 hours of in-window observation, and again whenever the metric is stale: a currently-blind metric makes no budget claim in either direction.

Per-customer overrides

Customers can carry per-SLO target overrides. See Customer scopes for the model.

Next

Was this page helpful?