> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# 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` 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

* A reporting metric. If one is not in place, complete
  [Define your first metric](https://docs.use.observer/docs/quickstart/first-metric.md) first.

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

> [!NOTE]
>
> **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.

**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:

```text title="error budget" theme={null}
good_samples         = samples that count as up (healthy or degraded), 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.

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](https://docs.use.observer/docs/concepts/slos-and-error-budgets.md)
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.

> [!NOTE]
>
> **Per-customer overrides**
>
> Customers can carry per-SLO target overrides. See
> [Customer scopes](https://docs.use.observer/docs/concepts/customer-scopes.md) for the model.

## Next

* [Publish your first status page](https://docs.use.observer/docs/quickstart/first-status-page.md)
* [Webhook payload reference](https://docs.use.observer/docs/reference/webhook-payloads.md) covers
  `slo.burn_started` and `slo.burn_resolved` payload shapes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.