Create an SLO
/api/slosParameters 1
datasetqueryTarget dataset. Overrides dash0.com/dataset in metadata.labels if both are provided.
Optional dataset to query across. Defaults to whatever is configured to be the default dataset for the organization.
"^[a-zA-Z0-9_-]{3,26}$"Sample request12345678910111213141516curl --request POST 'https://api.eu-west-1.aws.dash0.com/api/slos' \--header "Authorization: Bearer ${DASH0_AUTH_TOKEN}" \--header 'Content-Type: application/json' \--data-raw '{"apiVersion": "openslo/v1","kind": "SLO","metadata": {"name": "Example"},"spec": {"budgetingMethod": "Occurrences","objectives": [{}]}}'
Request body required
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.
Responses
The SLO was created.
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.