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.