Dash0 acquires Polar Signals

Last updated: September 15, 2026

Manage SLOs as Code

Version SLOs as OpenSLO documents and manage them through the Dash0 API with stable origins, idempotent upserts, optimistic locking, and YAML export.

SLOs are Dash0 assets that can be versioned and managed as infrastructure as code. An SLO's definition is an OpenSLO v1 document, so it stores naturally in Git, goes through code review like any other change, and deploys from CI.

SLOs as code run through the SLO API: any pipeline or tool that can send an HTTP request can create, update, and delete SLOs. This page covers the parts of the API that matter for a code-driven workflow; Create SLOs covers writing the SLO definition itself.

Set a stable origin

Give every code-managed SLO a dash0.com/origin label: your own stable identifier, such as a repository path or an IaC resource id.

yaml
1234
metadata:
  name: checkout-availability
  labels:
    dash0.com/origin: acme-observability-checkout-availability

The origin must be unique in the organization and must not start with slo_ or check_rule_. It buys you three things:

  • Addressability: every single-SLO endpoint accepts the origin in place of the server-issued slo_... id, so your pipeline never needs to store ids.
  • Idempotent applies: a PUT to an unknown origin creates the SLO, and the same PUT later updates it. See below.
  • Drift protection: SLOs that carry an origin are read-only in the UI. The detail page shows a Read-only tag naming the managing system, the Settings form cannot be saved, and the Enabled toggle is disabled, so the definition in your repository stays the truth. Admins can still delete them in the UI.

If you create an SLO with an auth token and omit the origin, the server assigns an api-... origin, and the SLO is read-only in the UI all the same.

Apply changes with PUT

PUT /api/slos/{origin} is the one call an apply step needs. It creates the SLO when the origin matches nothing, updates it when it exists, and restores it when it was deleted, so re-running a pipeline is always safe:

bash
1234
curl -X PUT "https://{your-dash0-api-host}/api/slos/acme-observability-checkout-availability?dataset=production" \
  -H "Authorization: Bearer $DASH0_TOKEN" \
  -H "Content-Type: application/json" \
  -d @checkout-availability.json

Writes require an auth token with the All permissions option; see Use the SLO API. DELETE /api/slos/{origin} soft-deletes the SLO, and a later PUT to the same origin restores it.

To guard against concurrent changes, send back the dash0.com/version label from your last read: the PUT is then rejected with 400 if someone changed the SLO in between. Omit the label to overwrite unconditionally, which is the usual choice when the repository is the single source of truth.

Export existing SLOs

To move an SLO that was built in the UI into your repository, export it as an OpenSLO document:

  • In the UI, open the SLO and choose Download as YAML from the overflow menu.
  • Through the API, request GET /api/slos/{originOrId}?format=yaml.

Responses use the openslo.com/v1 API version, which is also installable as a Kubernetes CRD, and a document you read back can be PUT as is. Strip the server-assigned dash0.com/id and dash0.com/version labels and the timestamp annotations before committing, and add your own dash0.com/origin. Applying that document then creates a new, code-managed SLO under your origin; recording starts fresh for it, and you delete the original UI-managed SLO once you are satisfied.

To reconcile what is deployed, list only the SLOs your pipeline owns with GET /api/slos?originPrefix={prefix}, using a shared prefix in your origins.

Further Reading