Dash0 acquires Polar Signals

Manage SLOs (Private BETA)

Retrieve a list of SLOs

get/api/slos

Parameters 2

datasetquery

Filter by dataset.

References Dataset

Optional dataset to query across. Defaults to whatever is configured to be the default dataset for the organization.

stringpattern "^[a-zA-Z0-9_-]{3,26}$"
originPrefixquery

Filter by origin prefix.

string
bash
Sample request
12
curl --request GET 'https://api.eu-west-1.aws.dash0.com/api/slos' \
--header "Authorization: Bearer ${DASH0_AUTH_TOKEN}"

Responses

List of SLOs.

array
References SloDefinition

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.

stringrequired
"openslo/v1""openslo.com/v1"
stringrequired
"SLO"
SloMetadatarequired
SloSpecrequired