Create an SLO

A Service Level Objective (SLO) that defines a target value or range of values for a service level, described by a Service Level Indicator (SLI). Implements a subset of the OpenSLO v1 specification (https://openslo.com/) with Dash0-specific extensions for access control, dataset scoping, and UI organization.

The API group accepts both the bare openslo/v1 (upstream OpenSLO v1) and the domain-qualified openslo.com/v1 on write; reads always return the domain-qualified openslo.com/v1. The domain-qualified form (a Dash0 drift from upstream OpenSLO v1's openslo/v1) is required so the same document is installable as a Kubernetes CustomResourceDefinition, whose API group must contain a dot.

Currently supported: a single objective with an inline ratioMetric indicator, Occurrences budgeting, and a rolling 4w (28d) time window.

Not currently supported — requests using any of these are rejected with a 400 (the one exception is alertPolicies, see below): thresholdMetric SLIs; indicatorRef; metricSource.metricSourceRef; multiple or composite objectives (compositeWeight, per-objective indicator/indicatorRef); threshold objective fields (op/value); time-slice objective fields (timeSliceTarget/timeSliceWindow); Timeslices and RatioTimeslices budgeting; and calendar-aligned time windows.

Alerting on SLOs (spec.alertPolicies) is not supported. Unlike the other unsupported fields, alertPolicies is accepted for OpenSLO compatibility but silently ignored — it is not stored, evaluated, or returned on read; see spec.alertPolicies for details.

SLOs evaluate with a fixed 5-minute settling delay applied automatically: at any moment, the SLI reflects telemetry that arrived at least 5 minutes ago. This ensures late-arriving signals are included in the SLI computation, at the cost of a small, fixed lag between live behavior and SLO state.

A Service Level Objective (SLO) that defines a target value or range of values for a service level, described by a Service Level Indicator (SLI). Implements a subset of the OpenSLO v1 specification (https://openslo.com/) with Dash0-specific extensions for access control, dataset scoping, and UI organization.

The API group accepts both the bare openslo/v1 (upstream OpenSLO v1) and the domain-qualified openslo.com/v1 on write; reads always return the domain-qualified openslo.com/v1. The domain-qualified form (a Dash0 drift from upstream OpenSLO v1's openslo/v1) is required so the same document is installable as a Kubernetes CustomResourceDefinition, whose API group must contain a dot.

Currently supported: a single objective with an inline ratioMetric indicator, Occurrences budgeting, and a rolling 4w (28d) time window.

Not currently supported — requests using any of these are rejected with a 400 (the one exception is alertPolicies, see below): thresholdMetric SLIs; indicatorRef; metricSource.metricSourceRef; multiple or composite objectives (compositeWeight, per-objective indicator/indicatorRef); threshold objective fields (op/value); time-slice objective fields (timeSliceTarget/timeSliceWindow); Timeslices and RatioTimeslices budgeting; and calendar-aligned time windows.

Alerting on SLOs (spec.alertPolicies) is not supported. Unlike the other unsupported fields, alertPolicies is accepted for OpenSLO compatibility but silently ignored — it is not stored, evaluated, or returned on read; see spec.alertPolicies for details.

SLOs evaluate with a fixed 5-minute settling delay applied automatically: at any moment, the SLI reflects telemetry that arrived at least 5 minutes ago. This ensures late-arriving signals are included in the SLI computation, at the cost of a small, fixed lag between live behavior and SLO state.