Skip to main content
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 or degraded. The gap between the target and the actual up time is tracked as an error budget. Every unhealthy sample burns the budget. The budget surfaces on status pages and in alerts.

​
Prerequisites

​
Steps

1

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.
2

Define the SLO

Open the service, then SLOs, then New SLO.Configure:
  • Metric: the metric defined in the previous quickstart page.
  • Target percentage: percentage of the window the metric must remain healthy or degraded. A common starting value is 99.9.
  • Rolling window: rolling window in days. A common starting value is 30.
  • Show on public status page: enables rendering on customer-facing status pages.
Save the SLO.
Choosing a targetThe 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.
3

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 recorded unhealthy samples in the window.
  • Latest burn event: the current or most recent period during which the error budget was negative, with its start, end (or open marker) and percent burned.
  • History: prior burn events in the window, with duration and budget cost.
The evaluator runs every 5 minutes. A new SLO reads collecting for its first 24 hours. After that, a burn event appears only if the budget goes negative.
4

Route burn alerts

Open Alerts and select Add destination (Slack, PagerDuty, generic webhook, and others). Under Alerts, choose Custom and select the slo.burn_started and slo.burn_resolved events, shown in the SLOs group as SLO started using budget fast and SLO budget use back to normal. SLO alerts go only to destinations set to All status pages (organization-wide):
  • slo.burn_started: the SLO’s error budget went negative. 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.
Available destinations depend on your plan.

​
Calculation

Each evaluator tick counts the metric’s samples in the moving window and recomputes:
error budget
The window never reaches back before the SLO was created, so deleting and recreating an SLO resets its epoch. Only unhealthy samples burn budget. A degraded sample (slower, but still serving) counts as up, the same rule SLA attainment uses by default. A no_data sample counts as up when the metric’s no-data treatment folds it to healthy or degraded. no_data samples are governed by the SLO’s unknown-data policy; under the default (down) they burn. Periods with no samples at all add nothing. 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. Whenever the metric is stale it reads No data: a currently-blind metric makes no budget claim in either direction.
Per-customer overridesCustomers can carry per-SLO target overrides. See Customer scopes for the model.

​
Next