Dash0 Raises $110M Series B at $1B Valuation

Last updated: May 29, 2026

Manage Notification Channels as Code

Define and manage notification channels using the Dash0 Operator for Kubernetes, Dash0 Terraform provider, and Dash0 CLI for version control, workflows, and automated deployment.

Notification channels are Dash0 assets that can be versioned and managed as infrastructure as code. This approach enables version control, automated deployment pipelines, consistent configuration across environments, and code review for notification routing changes.

Dash0 Operator for Kubernetes

Define notification channels as Dash0NotificationChannel custom resources that sync to Dash0, enabling workflows and native Kubernetes management.

Example

yaml
1234567891011121314
kind: Dash0NotificationChannel
metadata:
  name: platform-team-slack
spec:
  type: slack_bot
  config:
    channel: "#platform-team"
    teamId: T04QG2LAK7X
  frequency: 6h0m0s
  routing:
    filters:
      - - key: team
          operator: is
          value: platform
Tip

For more examples, including routing rules, see Configuration Options and Routing Rules.

The Dash0 Operator for Kubernetes watches for Dash0NotificationChannel resources and syncs them to your Dash0 organization. The operator reports status back on the custom resource.

Apply and Manage

bash
1234567891011121314
# Apply the notification channel
kubectl apply -f notification-channel.yaml


# List all notification channels
kubectl get dash0notificationchannels -n monitoring


# View details
kubectl describe dash0notificationchannel slack-platform-alerts -n monitoring


# Update the notification channel
kubectl edit dash0notificationchannel slack-platform-alerts -n monitoring


# Delete the notification channel
kubectl delete dash0notificationchannel slack-platform-alerts -n monitoring

Dash0 Terraform Provider

Manage notification channels in your Terraform infrastructure alongside other cloud resources for unified infrastructure management.

Example Usage

Slack Webhook:

hcl
123456789101112131415161718192021222324252627
terraform {
  required_providers {
    dash0 = {
      source  = "dash0hq/dash0"
      version = "~> 1.0"
    }
  }
}


provider "dash0" {
  url        = "https://api.dash0.com"
  auth_token = "auth_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}


resource "dash0_notification_channel" "slack_webhook" {
  notification_channel_yaml = <<-EOF
    kind: Dash0NotificationChannel
    metadata:
      name: Slack Alerts
    spec:
      type: slack
      config:
        webhookURL: "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"
        channel: "#alerts"
      frequency: 10m
  EOF
}

Webhook with Routing Rules:

Routing rules control which alerts are delivered to this channel. Each top-level list item is an OR group; conditions within a group are ANDed. In this example, notifications are sent when: (team.name = "sre" AND deployment.environment.name = "production") OR (service.severity = "critical")

hcl
12345678910111213141516171819202122232425262728293031323334353637
terraform {
  required_providers {
    dash0 = {
      source  = "dash0hq/dash0"
      version = "~> 1.0"
    }
  }
}


provider "dash0" {
  url        = "https://api.dash0.com"
  auth_token = "auth_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}


resource "dash0_notification_channel" "webhook_with_routing" {
  notification_channel_yaml = <<-EOF
    kind: Dash0NotificationChannel
    metadata:
      name: Production Alerts (Webhook with Routing)
    spec:
      type: webhook
      config:
        url: "https://example.com/webhook/production-alerts"
      frequency: 5m
      routing:
        filters:
          - - key: team.name
              operator: is
              value: sre
            - key: deployment.environment.name
              operator: is
              value: production
          - - key: service.severity
              operator: is
              value: critical
  EOF
}

For more examples and related information, see the Dash0 Terraform provider documentation.

Dash0 CLI

Script notification channel operations with the Dash0 CLI for automated deployments and batch operations.

Create from File

bash
12
# Create a notification channel from a YAML file
dash0 -X notification-channels create -f slack-alerts.yaml

List Channels

bash
1234567891011
# List all notification channels
dash0 -X notification-channels list


# List all notification channels as YAML
dash0 -X notification-channels list -o yaml


# List all notification channels in JSON format
dash0 -X notification-channels list -o json


# List all notification channels as CSV
dash0 -X notification-channels list -o csv

Get Channel Details

bash
12345678
# Get a single notification channel as YAML
dash0 -X notification-channels get <id> -o yaml


# Get channel details in JSON format
dash0 -X notification-channels get <id> -o json


# Get channel details in table format
dash0 -X notification-channels get <id> -o table

Update Channel

bash
12
# Update an existing notification channel
dash0 -X notification-channels update <id> -f slack-alerts-updated.yaml

Delete Channel

bash
12
# Delete a notification channel
dash0 -X notification-channels delete <id>

For more information, see the Dash0 CLI documentation.

Configuration Options

Channel Definition Format

Each notification channel is defined as a YAML document with kind: Dash0NotificationChannel.

The spec.type field selects the channel type and spec.config holds the type-specific settings.

Example: PagerDuty notification channel

yaml
1234567891011121314151617181920
kind: Dash0NotificationChannel
metadata:
  name: pagerduty-oncall
spec:
  type: pagerduty
  config:
    key: your-integration-key-here
    url: ""
  frequency: 6h0m0s
  routing:
    filters:
      - - key: service.name
          operator: is
          value: productcatalogservice
      - - key: service.name
          operator: is
          value: frontend
        - key: dash0.resource.type
          operator: is
          value: synthetic
Tip

For information on frequency, see Frequency and for information on routing.filters, see Routing Rules.

Frequency

The frequency field controls rate limiting to prevent notification storms. Dash0 will not send more than one notification per channel within the specified time window.

yaml
123
spec:
  type: slack
  frequency: 10m  # Maximum one notification per 10 minutes

Common values:

  • 5m - High-priority channels (PagerDuty, oncall)
  • 10m - Standard channels (team Slack channels)
  • 30m - Low-priority channels (email summaries)

Routing Rules

Routing rules determine which failed checks trigger notifications on a channel.

Dash0 provides two ways to associate check rules with notification channels via infrastructure as code:

  • Direct assignment — Notification channels can be referenced by ID from individual check rules, as described in Manage Check Rules as Code:

dash0.com/notification-channel-ids: ded5721c-2bf0-4a10-ab33-511fef734b0f,56aaacb2-10c6-4cef-8aeb-d7c862ad863e

  • Label-based routing — Each channel can decide which failed checks it notifies on through its own routing rules: when a check fires, Dash0 evaluates every channel's routing.filters, as explained below, against the labels and attributes of the failed check and delivers the notification on each channel whose filters match.

    To send a check rule's alerts to a specific channel:

    • Make sure the check emits labels or attributes — such as team, service.name, or dash0.resource.type — that match the channel's routing filters.
    • To route by severity, filter the channel on dash0.failed_check.max_status (degraded or critical), as shown in the examples below.

Basic Routing by Label

Route alerts based on a single label match:

yaml
1234567891011121314
kind: Dash0NotificationChannel
metadata:
  name: platform-team-slack
spec:
  type: slack_bot
  config:
    channel: "#platform-team"
    teamId: T04QG2LAK7X
  frequency: 6h0m0s
  routing:
    filters:
      - - key: team
          operator: is
          value: platform

This channel receives alerts from any check rule that has the label team=platform. The filters array contains one condition (the outer array), which itself contains one matcher (the inner array). Since there's only one condition with one matcher, this is a simple equality check.

Multiple Conditions (OR Logic)

Route alerts that match ANY of the specified conditions (disjunction):

yaml
1234567891011121314151617
kind: Dash0NotificationChannel
metadata:
  name: platform-team-slack
spec:
  type: slack_bot
  config:
    channel: "#platform-team"
    teamId: T04QG2LAK7X
  frequency: 6h0m0s
  routing:
    filters:
      - - key: team
          operator: is
          value: platform
      - - key: team
          operator: is
          value: sre

This channel receives alerts labeled team=platform OR team=sre. The filters array contains two conditions (two items in the outer array), and conditions are combined with OR logic. Each condition contains a single matcher, so an alert matches if it has either label value.

Multiple Matchers per Condition (AND Logic)

Require ALL matchers within a condition to match (conjunction):

yaml
1234567891011121314151617
kind: Dash0NotificationChannel
metadata:
  name: platform-team-slack
spec:
  type: slack_bot
  config:
    channel: "#platform-team"
    teamId: T04QG2LAK7X
  frequency: 6h0m0s
  routing:
    filters:
      - - key: service.name
          operator: is
          value: frontend
        - key: dash0.failed_check.max_status
          operator: is
          value: critical

This channel only receives alerts where service_name=frontend AND dash0.failed_check.max_status=critical. The filters array contains one condition (one item in the outer array), but that condition contains two matchers (two items in the inner array). Matchers within the same condition are combined with AND logic, so both must be true for the alert to be routed to this channel.

Complex Routing (AND + OR)

Combine multiple conditions with multiple matchers:

yaml
123456789101112131415161718192021222324252627
kind: Dash0NotificationChannel
metadata:
  name: critical-backend-services
spec:
  type: pagerduty
  config:
    key: your-integration-key
    url: ""
  frequency: 6h0m0s
  routing:
    filters:
      # Condition 1: Critical alerts for checkout service
      - - key: service.name
          operator: is
          value: checkout
        - key: dash0.failed_check.max_status
          operator: is_one_of
          values:
            - CRITICAL
      # Condition 2: Critical alerts for payment service
      - - key: service.name
          operator: is
          value: payment
        - key: dash0.failed_check.max_status
          operator: is_one_of
          values:
            - CRITICAL

This routes alerts where:

  • (service_name=checkout AND dash0.failed_check.max_status=critical) OR
  • (service_name=payment AND dash0.failed_check.max_status=critical)

The filters array contains two conditions (two items in the outer array), and each condition contains two matchers (two items in each inner array). Within each condition, both matchers must match (AND logic). Across conditions, only one condition needs to match (OR logic). This pattern lets you route alerts from multiple services but only when they reach critical severity.

Further Reading