Dash0 acquires Polar Signals

Last updated:

Manage SLOs as Code

Version SLOs as OpenSLO documents and manage them with the Dash0 Terraform provider or the Dash0 CLI, with stable origins, idempotent applies, 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.

Two tools apply that document for you:

  • Dash0 Terraform provider: the dash0_slo resource takes the OpenSLO document in its slo_yaml attribute and manages the SLO's lifecycle alongside your other infrastructure.
  • Dash0 CLI: the dash0 slos command group creates, lists, gets, updates, and deletes SLOs, and dash0 apply -f <file|directory> applies OpenSLO YAML documents, so it slots into any scripted deployment.

Both authenticate with an auth token that has the All permissions option. This page covers the mechanics of the code-driven workflow; Create SLOs covers designing the SLI and target.

Set a stable origin

Give every CLI-managed SLO a dash0.com/origin label: your own stable identifier, such as a repository path or a resource id. Terraform manages the origin for you, exposed as the resource's read-only origin attribute.

yaml
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: the origin identifies the SLO everywhere, so your pipeline never needs to store server-issued slo_... ids.
  • Idempotent applies: applying a document creates the SLO when its origin matches nothing and updates it when it exists, so re-running a pipeline is always safe. A document without an origin creates a new SLO on every apply, so pin dash0.com/origin for anything applied more than once.
  • 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.

An SLO created as code without an explicit origin still gets one assigned automatically, and is read-only in the UI all the same.

Apply changes

  • Terraform: terraform apply creates, updates, and deletes the SLO with the rest of the plan. To bring an SLO that already exists under management, use terraform import dash0_slo.<name> "{dataset},{id_or_origin}".
  • Dash0 CLI: dash0 apply -f <file|directory> upserts every document by its origin, and dash0 slos delete removes one. Deletes are soft: applying a document whose origin belongs to a deleted SLO restores it.

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.
  • With the CLI, dash0 slos list -o yaml exports the full definitions as a multi-document YAML stream, suitable for committing or piping straight to dash0 apply -f -.

Exported documents use the openslo.com/v1 API version, which is also installable as a Kubernetes CRD. 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 see which SLOs are code-managed and under which origin, dash0 slos list -o wide includes an ORIGIN column.

Further Reading