Last updated: July 7, 2026
About Service Level Objectives (SLOs)
A Service Level Objective (SLO) is a target for how reliable a service should be, measured against a real signal from your telemetry. Think of an SLO as OKRs for reliability: a way to map a technical goal — latency, availability, error rate — to the business outcome it supports, with a shared target everyone can rally around.
In Dash0, an SLO is best understood as an extension of a check rule. Instead of firing the moment a threshold is crossed, an SLO tracks an error budget over a time window and tells you how fast that budget is being consumed. This shifts the question from "did this one request fail?" to "is the service as reliable as our users expect?"
SLOs are in Private Beta and enabled per organization by the Dash0 team. Once enabled, you will see SLOs under Alerting. If you do not see it, contact your Dash0 representative.
An SLO vs. a check rule
Compared with a check rule, an SLO is:
- Visualized differently — SLO gauges, error-budget burndown charts, and burn-rate views instead of a simple pass/fail.
- Evaluated differently — alerts trigger on error-budget consumption (burn rate) rather than on each individual violation.
Because of this, SLOs have their own entry in the navigation (under Alerting), the same way synthetic checks are kept separate even though they are also built on check rules.
Key concepts
| Term | What it means |
|---|---|
| SLI (Service Level Indicator) | The measurement of how the service is performing. In Dash0 this is a ratio of good events to total events, expressed as PromQL over your telemetry (for example, non-error spans divided by all server spans). |
| SLO target | The reliability goal, usually a percentage (for example 99.7%). It determines how many bad events are tolerated within the time window. |
| Error budget | The allowed amount of failure (1 − target) over the time window. With occurrence-based budgeting — the method used in the Private Beta — it is measured as bad events versus total events over the window. |
| Time window | The period the SLO is measured over. In the Private Beta this is a rolling 28-day window. |
| Burn rate | How fast the error budget is being consumed relative to the budget available. A burn rate of 1× exactly exhausts the budget by the end of the window; higher means faster. |
| Fast burn | A high, short-lived burn rate that needs immediate attention (about 14.4×, roughly 5% of a 30-day budget in about an hour). |
| Slow burn | A lower burn rate (just above 1×) sustained over a longer window; important but less urgent, and it may self-correct. |
What you can measure
An SLI is a raw measurement of how a service is performing — most commonly availability, latency, or error rate — pulled from your telemetry. Common SLO blueprints include:
- Availability / uptime — the share of requests served without an error status over the window.
- Latency — the share of requests served faster than a target threshold.
The same model extends to more specific cases such as pipeline, database, and AI-service SLOs.
What is in the Private Beta
Available Today
- Create and manage SLOs through the Dash0 API. See Create SLOs.
- View all SLOs in the SLOs catalog (under Alerting › SLOs) and open a detail page for any single SLO: target, error budget remaining, per-window compliance, a burndown chart, and burn-rate views. See View and analyze SLOs.
- Custom labels and annotations on SLOs, with label-based filtering.
- Continuous evaluation that exposes a set of SLO metrics.
Arriving During the Private Beta
- A self-serve SLO creation UI (creation is API-only today).
- The final SLO catalog UI: browse SLOs grouped by service, with health, sorting, and filtering.
- Deep links from an SLO to its underlying logs and traces.
Planned for Later
- Metrics-based triage (triage initially targets trace-based SLOs).
- A fuller folders and access-control experience — folder paths (
dash0.com/folder-path) and read-access sharing (dash0.com/sharing) are already available through the API.