Component schema

SloDefinition

object4 direct references

Definition

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

Used by 4

These schemas and endpoints reference this type directly.

EndpointGET /api/slosEndpointPOST /api/slosEndpointGET /api/slos/{originOrId}EndpointPUT /api/slos/{originOrId}

json

OpenAPI source123456789101112131415161718192021222324252627282930
{
  "description": "A Service Level Objective (SLO) that defines a target value or range of values for a\nservice level, described by a Service Level Indicator (SLI).\nImplements a subset of the OpenSLO v1 specification (https://openslo.com/) with\nDash0-specific extensions for access control, dataset scoping, and UI organization.\n\nThe API group accepts both the bare `openslo/v1` (upstream OpenSLO v1) and the\ndomain-qualified `openslo.com/v1` on write; reads always return the domain-qualified\n`openslo.com/v1`. The domain-qualified form (a Dash0 drift from upstream OpenSLO v1's\n`openslo/v1`) is required so the same document is installable as a Kubernetes\nCustomResourceDefinition, whose API group must contain a dot.\n\nCurrently supported: a single objective with an inline `ratioMetric` indicator,\n`Occurrences` budgeting, and a rolling `4w` (28d) time window.\n\nNot currently supported — requests using any of these are rejected with a 400 (the one\nexception is `alertPolicies`, see below): `thresholdMetric` SLIs; `indicatorRef`;\n`metricSource.metricSourceRef`; multiple or composite objectives (`compositeWeight`,\nper-objective `indicator`/`indicatorRef`); threshold objective fields (`op`/`value`);\ntime-slice objective fields (`timeSliceTarget`/`timeSliceWindow`); `Timeslices` and\n`RatioTimeslices` budgeting; and calendar-aligned time windows.\n\nAlerting on SLOs (spec.alertPolicies) is not supported. Unlike the other unsupported\nfields, `alertPolicies` is accepted for OpenSLO compatibility but silently ignored — it\nis not stored, evaluated, or returned on read; see spec.alertPolicies for details.\n\nSLOs evaluate with a fixed 5-minute settling delay applied automatically: at any\nmoment, the SLI reflects telemetry that arrived at least 5 minutes ago. This\nensures late-arriving signals are included in the SLI computation, at the cost of a\nsmall, fixed lag between live behavior and SLO state.\n",
  "properties": {
    "apiVersion": {
      "type": "string",
      "enum": [
        "openslo/v1",
        "openslo.com/v1"
      ]
    },
    "kind": {
      "type": "string",
      "enum": [
        "SLO"
      ]
    },
    "metadata": {
      "$ref": "#/components/schemas/SloMetadata"
    },
    "spec": {
      "$ref": "#/components/schemas/SloSpec"
    }
  },
  "required": [
    "apiVersion",
    "kind",
    "metadata",
    "spec"
  ]
}