Recent changes and improvements to Dash0

At real scale, most telemetry is never looked at, but it all gets stored and paid for anyway. SignalControl is Dash0’s ingestion pipeline: it filters, samples, and aggregates telemetry the moment it arrives, before anything is stored, so you keep the signal and stop storing the noise. It is included with every account from today. There is nothing to buy or enable, and until you create a rule, everything passes through untouched.

What it does

Spam filters. Drop known noise at ingestion, for every signal type. Each filter charts exactly what it catches over time, so you always know which rules are earning their keep.

Distributed tail sampling. You choose what to keep and what to sample out, and the decision is made only after the whole trace is visible. What makes Dash0’s version different is that it works no matter where the trace’s spans land: different collectors, even different clusters. Tail sampling normally requires every span of a trace to pass through the same collector so it can be judged as a whole, which means re-plumbing your pipeline and makes that collector the bottleneck at exactly the scale where sampling matters most. Dash0 separates the sampling decision from the collectors themselves, so a whole fleet reaches one consistent keep-or-drop decision per trace, whatever your topology. The typical setup keeps every error, outlier, and slow request and samples out routine successes, but the rules are yours, and changes apply live with no collector restart.

RED metrics before sampling. Rate, error, and duration metrics are computed from 100% of spans before sampling drops anything, whether sampling runs at the Edge or in Dash0's cloud. If metrics came only from the traces you keep, dashboards would show the exceptions, not the truth. Sampling changes which traces you keep, never what your dashboards say.

Signal to metrics. Convert chosen attributes of spans and logs into metric series: filter the signals you care about, pick the attributes to carry through, and get latency histograms from spans and counters from logs. Computed before sampling, so the metrics reflect all traffic.

Time series aggregation. Aggregate metrics temporally (downsample 15-second scrapes to the resolution you actually chart) or spatially (collapse per-pod series into one per-service series), with the aggregate staying exact. Runs in Dash0’s cloud after ingestion, where metrics from every source converge.

Everything SignalControl drops is visible as kept versus dropped, per rule, so reduction is something you verify rather than trust.

Two ways to run it

SignalControl Managed runs in Dash0’s cloud. Send telemetry as you do today; nothing to deploy.

SignalControl Edge runs in your own Kubernetes cluster, as a gateway behind your existing central collector. Telemetry is enriched, filtered, measured, and sampled before it leaves your network, which also cuts egress. Nothing upstream of it changes, and your existing destinations keep receiving exactly what they receive today.

Either way, rules are managed in Dash0, in the UI or as code, and changes apply live with no restarts.

With the new ingestion and storage pricing, signals pay a small ingestion fee and storage prices apply only to what you keep, so what SignalControl drops never hits the storage line of your bill. Existing accounts move to the new pricing at the start of a billing period, never mid-period; see the pricing page for rates.

Monitoring a cloud service should not mean collecting every metric from every resource. You can now narrow collection to the resources you care about, down to a single service, and choose metrics one by one. Dash0 scrapes only what you select, giving you more control over metric volume and collection costs.

In your GCP integration’s Metrics tab, add filter conditions to choose which resources to monitor, then select the metrics to collect. The resource counts show how many resources are included and excluded before you save.

The same controls apply to the newly supported services: select the services you need, scope the resources, and collect the metrics that matter.

Mattermost is now a notification channel of its own. Paste an incoming webhook URL and Dash0 posts these in Mattermost's own layout:

• Alerts
• Synthetic check failures
• Agentic workflow runs

Labels and annotations

Labels and annotations go into the collapsed info panel, so the post stays readable and the detail is still one click away. Alerts carry an Analyse with Agent0 link that opens the failed check in Agent0 with its time range already set.

More details on how to set up the integrations can be found in our integration hub.

Few engineering teams all use the same operating system. If part of your team works on Windows, their AI coding sessions never reached Dash0. That gap is now closed.

The Dash0 agent plugins now ship Windows binaries for amd64 and arm64, for all four agents.

More details on how to set up AI Coding Insights can be found in the Integrations Hub.

Not every question belongs in a channel. You want to check a service before you raise it with the team, or work in a dataset nobody else touches, and the choice was to post it where everyone reads it or leave Slack for the Dash0 UI. So the quick question does not get asked.

Agent0 now answers direct messages. Message @Dash0 a question, no tag needed, and the answer lands in a thread only you can read. The first time, it asks which organization and dataset to use, and that choice is yours alone: a channel's applies to everyone in it, so two people in the same workspace can point their DMs at different datasets. Every answer carries the pair it used, next to a Change organization / dataset button. Agent0 answers as you, using your Dash0 account, so it reads exactly the data you can read.

Cardinality is now a metric. dash0.metrics.timeseries reports your distinct series count as a time series, so it works anywhere a metric works: a dashboard panel, a PromQL query, an alert check.
dash0.metrics.timeseries is synthetic, computed from metric data you already sent, so there is nothing to turn on and no extra charge. Like every synthetic metric it carries no attributes of its own. You pick the dimensions by grouping in PromQL (or via the Query Builder):

1
topk(10, sum by (otel_metric_name) ({otel_metric_name="dash0.metrics.timeseries"} offset 5m))

That gives you your ten largest metrics by series count.

otel_metric_name appears twice, and that is deliberate. The first matcher selects the synthetic metric. The second filters the data points underneath by their own metric name, so you can pin a single metric:

1
sum({otel_metric_name="dash0.metrics.timeseries", otel_metric_name="k8s.container.ready"} offset 5m)

Use an offset between five and ten minutes. Dash0 syncs the underlying metric metadata with a short delay, and without the offset the last few minutes of the chart trail off toward zero.

Grouping by a resource attribute answers the other question, where the series come from rather than which metric they belong to. sum by (k8s_namespace_name) finds the namespace, sum by (service_name) finds the service.

More information

• The metric registry has the full definition
• Understand Synthetic Metrics covers how synthetic metrics are queried.

An alert lands in Slack and the work starts somewhere else. You open the check in a browser tab, piece together what the alert already knew, and type the question out again. By the time there is an answer, the conversation about it has moved on.

Alerts now carry a Fix this in thread button. One click asks Agent0 to explain the failing check, why it happened, what it affects, and whether it needs fixing, and the answer lands in the alert's own thread where the team is already talking. Agent0 shows its thinking steps as it works, and it reads the organization and dataset from the alert itself, so nobody has to tell it where to look. Follow-ups work the same way: tag @Dash0 in the thread.

Dash0 apply has so far been focused on creating and updating assets. Deleting was on you: delete a definition from your repo, and the asset stayed in Dash0 until somebody removed it by hand.

The new apply -f <directory> --since <ref> option handles the full synchronization. Give it a git reference (a commit hash or a branch), and it compares the asset definitions in that ref against what apply -f resolves to now. Anything in the git reference that is not there anymore in the directory gets deleted.

dash0 apply -X -f ./assets --dry-run --since HEAD~1

Dry run: 2 documents from 2 files validated; 1 deletion pending due to --since 'HEAD~1'
checkout-overview.yaml

* Apply Dashboard "Checkout Overview"
legacy-errors.yaml
* Delete View "Legacy Errors" (view_legacy_errors)
payments-latency.yaml
* Apply Dashboard "Payments Latency"

The apply -f <directory> --since <ref> also handles moving assets among files. As long as the id or the origin is in some file, the asset won’t get deleted.

Stay tuned for more: we are working on a full dash0 diff command, and a GitHub Action so that the new apply -f <directory> --since <ref> workflow fits without any toil into your CD.

Connecting GitLab gives Agent0 the code behind your telemetry. It reads diffs, issues and pipeline results while it investigates, so a root cause lands against the change that caused it rather than against a metric on its own. Ask what changed in merge request !412 and it reads the diff, in the thread rather than in another tab.

That context is also what lets it act. Ask Agent0 to fix the bug and it clones the project, commits to a feature branch, pushes, and opens a merge request with deep links back to the telemetry that prompted it.

Getting started

Setup takes two steps. An admin adds the GitLab connector under Settings → Integrations and connects the organization, then every member connects their own account.

Set Up GitLab Integration has the service account, self-managed and webhook detail.

Use GitLab in Chat covers how Agent0 behaves once you are connected.

Your name, your permissions

Agent0 works in GitLab through the account you connect yourself. A merge request it opens is yours, not a bot's, and it reaches exactly what you can reach. If a project is invisible to you, it stays invisible to Agent0.

Nothing falls back to a shared Dash0 identity, and that holds in automations too. An automation acts as the person who created it, so the merge requests it opens are theirs. One exception: an automation that records no creator has nobody to act as, which covers those made by Terraform, the CLI, the API, or by another automation.

One limit worth stating plainly: Agent0 will not push to a default branch. Changes arrive as a merge request from a feature branch, every time.

Controls

• Disconnect your account from the integration page, or revoke Dash0 from GitLab's authorized applications.
• Admins can delete the integration, which takes the organization's stored credentials with it. The webhook survives in GitLab, so delete that there too.
• No new charge. The GitLab integration is not billed.

Alerts land in Slack, and incidents get investigated in a thread. By then the thread already holds the context: what changed, who deployed, what somebody ruled out. Tag @Dash0 in it and Agent0 starts from that context. The answer lands in front of the whole channel, so nobody has to relay findings, and anyone can pick it up with a follow-up.

Ask it what you would ask in Dash0:
- @Dash0 what caused this alert?
- @Dash0 find the bug behind these errors and open a PR with the fix.
- @Dash0 find the logs for order 4f2c1a in the last hour.
- @Dash0 how many 5xx did we serve yesterday, per service?
- @Dash0 add a p95 latency panel to the checkout dashboard.
- @Dash0 alert us when checkout latency goes over 500ms.

This is the same agent that runs in Dash0. It queries your telemetry, calls the MCP servers you have connected, reads your source code, and, with the GitHub connector set up, opens a PR. It answers as the person who tagged it, with that person's Dash0 permissions. Invite it to any channel and it is there. See Ask Agent0 in a Slack Channel for the details, and Set Up Slack Integration to install the app.