Recent changes and improvements to Dash0

Keeping alerting configuration in sync across environments has always been tedious.You can now manage notification channels — Slack, PagerDuty, email, webhooks, and more — as code using the Dash0 CLI, Terraform provider, and Kubernetes operator.

Notification channels control where Dash0 sends alerts when check rules fire. Until now they could only be configured through the UI, which made it difficult to version-control, review, and replicate them across organizations. With IaC support, you define a channel once in a YAML file and apply it from your terminal, CI/CD pipeline, or GitOps workflow.

How it works

Each notification channel is defined as a CRD-enveloped YAML document with kind: Dash0NotificationChannelCopy.The spec.typeCopy field selects the channel type (one of 17 supported integrations), and spec.configCopy holds the type-specific settings such as webhook URLs or Slack channel names.Notification channels are organization-level resources, so no --datasetCopy flag is required.

Dash0 CLI

Since v1.9.0:

notification-channel-cli.sh
1234567891011121314
# Create a notification channel from a YAML file
dash0 notification-channels create -f slack-alerts.yaml

# List all notification channels
dash0 notification-channels list

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

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

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

Terraform provider

Since v1.8.0:

notification-channel.tf
123
resource "dash0_notification_channel" "slack_alerts" {
  notification_channel_yaml = file("${path.module}/channels/slack-alerts.yaml")
}

Import existing channels with terraform import dash0_notification_channel.slack_alerts <origin>Copy.

Kubernetes operator

Since v0.136.0:

notification-channel.yaml
123456789101112131415
apiVersion: operator.dash0.com/v1alpha1
kind: Dash0NotificationChannel
metadata:
  name: slack-alerts
  namespace: monitoring
spec:
  content: |
    kind: Dash0NotificationChannel
    metadata:
      name: Slack Alerts
    spec:
      type: slack
      config:
        url: "https://hooks.slack.com/services/T00/B00/xxxx"
      frequency: 10m

The operator syncs the channel to Dash0 and reports status back on the custom resource.

What's New

Full SQL Support: Write SQL against logs, spans, and web events. Joins, subqueries, aggregations. Functions for aggregation, string manipulation, date, array, math, logic, JSON extraction, and type conversion are supported. Because it's standard SQL, any AI tool can write queries for you — just describe what you want and paste the result in. See the full function reference in the docs.

Cross-signal joins and aggregation on arbitrary attributes unlock questions no single explorer can answer. Join spans to themselves to compute connection KPIs across service boundaries. Pull custom span attributes — query IDs, URL parameters, business-specific flags — alongside performance data to understand not just that something is slow, but which request types are responsible.

Built-in Query Templates: A library of ready-to-run query examples ships with Dash0 SQL. Pick a template, run it, and modify it from there — no blank-page problem.

Recent Queries: Dash0 SQL keeps a local history of your last 20 queries. Get back to anything you ran earlier without rewriting it from scratch.

Saved Views with Sharing: Save any query as a named view that lives in Dash0 and persists across sessions and devices. Share saved views with teammates so the whole team can build on the same go-to queries.

We've added drag-to-resize handles to table columns across Dash0's explorers. Hover over the table header row to reveal grip handles at column edges, then drag to adjust the width. Save your view to keep your preferred column sizes across sessions.

To reset column sizes, use the view reset button. If you've saved a view with custom column sizes, a "Reset column sizes" button will appear in the table Settings menu.

Available in: Trace Explorer, Log Explorer, Web Events Explorer, and Resources.

If you're using a shared web integration across multiple domains — think franchise networks, regional storefronts, or white-label deployments — you've probably wondered which domain a particular session was visiting. Until now, there was no way to tell from the Dash0 UI.

This update surfaces the page.url.domainCopy attribute in three places:

Session list sidebar

The session summary card now shows the domain alongside location and browser info, so you can identify which site a user was on at a glance.

Session detail page

When viewing a full session, the domain appears in the header for quick context as you step through page views and events.

Dashboard filters

A new Domain filter variable is available in both the Overview and Web Vitals dashboards, letting you slice metrics by domain across your entire network.

Also in this update:

• On smaller screens, the session detail header items no longer get squeezed — they now wrap gracefully instead.

How It Works

When you add Dash0 as an MCP server in your AI tool of choice, the tool will automatically open a browser window where you log in and grant consent — just like connecting any other app. Behind the scenes, Dash0 handles dynamic client registration, token exchange, and automatic refresh. You never touch a token.

For example, in Claude Code

1
claude mcp add --transport http dash0 {{endpoint_mcp}}

That's it. Claude Code will walk you through the OAuth flow on first use.

Why This Matters

• No more token management. You don't need to visit the Dash0 UI to create an auth token, copy it into your config, and remember to rotate it.
• Short-lived, auto-refreshing tokens. Access tokens expire in 15 minutes and refresh automatically - reducing the blast radius if a token is ever compromised.
• Full audit trail. Every OAuth authorization, token exchange, and revocation is tracked in your organization's audit log.
• Revocable at any time. You can review and revoke connected applications from your Dash0 settings (User Settings -> ApplicationsCopy).

What You Get

Once connected, your AI tool has access to 20+ MCP tools for querying your observability data - service catalogs, PromQL metrics, logs, traces, synthetic checks, dashboards, and more. All scoped to your user permissions and dataset access.

Traditional Tokens Still Work

If you prefer managing tokens yourself - for CI pipelines, scripts, or automated workflows - bearer token authentication remains fully supported. OAuth is an additional option, not a replacement.

Click a legend entry to isolate that series — all other series are hidden so you can focus on the one that matters. Shift+click to select multiple series and build the exact comparison you need. Click the isolated entry again to restore all series.

This interaction model is now applied consistently across all charts in Dash0: dashboards, explorers, and detail views. No more guessing which legend behavior you will get.

How It Works

When you open a failed check's details view, Dash0 analyzes the PromQL expression behind the check and extracts the metric names and label filters. The drilldown then uses these filters to show you only the telemetry that matters:

• Spans, Logs, and Web Events cards appear only when the check uses a related synthetic metric (e.g., dash0.spansCopy or dash0.spans.durationCopy), with extracted filters pre-applied for a precise view.
• Metrics cards list all other metrics used in the check, each filtered to the relevant label matchers.

Not every filter from a PromQL expression can always be mapped to a telemetry query — Dash0 applies what it can and skips what it can't, so you always get the most relevant view possible. Although, the only times we need to skip some of the filters are for the most complex PromQL queries. (If you want to know more, hit Michele up and prepare for an entire discussion about symbolic model-checking on the PromQL AST. It is great fun!)

OK, but can you be more practical about it?

The following PromQL query:

(sum(increase({otel_metric_name="dash0.spans", otel_span_status_code="ERROR"}[5m])) * histogram_quantile(0.95, sum by(le) (rate({otel_metric_name="dash0.spans.duration", otel_span_status_code="ERROR"}[5m])))) / (sum(increase({otel_metric_name="dash0.logs", otel_log_severity_range="ERROR", service_name="checkoutservice"}[5m])) + 1)Copy

Error span processing time per error log in the checkout service

The metric shows how much error span processing time (at P95) occurs for each error log generated by the checkout service. This is useful for:

• Identifying if checkout errors generate disproportionate tracing overhead
• Correlating checkout service error logging patterns with distributed trace complexity
• Detecting when checkout errors trigger cascading failures across services (high values = many error spans per checkout log)

When looking at the Failed Check Details page for an alert using this query:

• The spans shown are only those with status code ERRORCopy, across all services
• The logs shown are those with severity range ERRORCopy for the checkoutserviceCopy.

Now, we could have picked a simpler PromQL expression, but where's the fun in that. You would have looked at it, assumed it just extracted somehow the filters from the timeseries, and phoned it in. In reality, the algorithm does a lot of work with binary operators (+Copy, -Copy, *Copy, /Copy), logic operators (ANDCopy, ORCopy, UNLESSCopy), and more.

Want to Try It?

Open the Failed Checks page, select a failed check, and explore the drilldown cards. Brush a time range in the timeline chart to jump directly into the relevant telemetry.

Kudos where kudos are due

The lion's share of the research that led to this breakthrough has been performed in collaboration with Julius Volz (who else to rely upon to know all the dark corners of PromQL?!?).

Julius' course about "Understanding PromQL" is a rite of passage for technical staff at Dash0, and we cannot endorse it enough!

If you've used both the Query Builder and the dashboard panel editor, you may have noticed they were starting to feel like two different products. Different layouts, different behaviors, different quirks. We've fixed that.

The Query Builder now uses the same interface as the dashboard panel editor. This means a more consistent experience across Dash0, and as we add new widget types to dashboards, they'll automatically be available in the Query Builder too.

It is complicated to troubleshoot why particular PromQL expressions to not return timeseries, and the workarounds with the OR operator have been historically difficult to learn.

Dash0 worked with the Prometheus community to fix these gaps, and we just shipped the result in Dash0.

How it works

The fillCopy modifier lets you substitute a default value for missing series in a binary operation. Three variants cover every scenario:

• fill(<value>)Copy applies the default to whichever side is missing, e.g.
  http_requests_total / fill(1) capacity_totalCopy
• fill_left(<value>)Copy substitutes only when the left-hand side has no match:
  (vector(0) > 1) / fill_left(0) requests_totalCopy (the left side is always empty, and the fillCopy operator handles it)
• fill_right(<value>)Copy substitutes only when the right-hand side has no match: requests_total / fill_right(1) (vector(0) > 1)Copy (the right side is always empty, and the fillCopy operator handles it)

Notice that, however, when both sides of an operator are missing, no time series is generated.

(We did wonder if the fillCopy behaviour should have been the default, using fill(0)Copy for addition and subtraction, fill(1)Copy for multiplication, and fill_right(1)Copy for division, but that would have been a breaking change for the Prometheus community.)

What changed

The fillCopy operator is now available via the UI and the API in Dash0. Enjoy :-)

Want to know more?

For a detailed walkthrough of the problem and the fillCopy solution, see the excellent Filling in Missing Series in Binary Operator Matching blog from PromLabs.

Want to learn more about PromQL in general?

We cannot recommend enough the Understanding PromQL course by PromLabs. Taking that course is effectively a right of passage for Dash0 engineers and product people :-)

A deprecation long overdue

OpenTelemetry is deprecating span events in favour of log records linked with trace context. Given just how many times we are asked "Should it be a span event or a log record?" by our customers, we are overjoyed at this streamlining in OpenTelemetry.

Span events exist because, in the beginning of the OpenTelemetry project, tackling logs as a separate signal felt like trying to bite off too much. But events like uncaught exceptions were still needed in the model, and so span events were introduced.

Now that logs in OpenTelemetry are stable in terms of specification, and implementation is complete or well underway in pretty much all SDKs, span events are no longer necessary. But, realistically, instrumentations generating span events will remain in use for a considerable time.

The new world, today

To help you with the transition, we have introduced an opt-in, per-dataset option to automatically convert span events into correlated log records during ingestion.

The resulting log records have the correct trace context on them, and "just work" the way you would expect. And in order for you to find out how many span events have been converted to logs, we add to the latter the dash0.span_event.converted = trueCopy log attribute.

That is, you do not need to modify your instrumentation, we just "fix your telemetry" for you. (But if you do want to fix your instrumentation, these agent skills we published a few weeks ago can help with the migration!)

Opting in to converting span events to logs will also hide the "Span events" column in your "All spans" Tracing view, but if you want, you can "bring it back" adding the Span event column to a custom view.

No impact on pricing

Span events and log records have always been equivalent in terms of pricing, as we saw this transition coming a long way.

The only effect on your bill is that the amount for "Spans and span events" will decrease by the same amount that "Logs" increases, based on how many span events you send.