Teach Agent0 the procedures only your team knows. An admin can now write custom skills for your organization, and anyone can call one in a chat with /, or let Agent0 pick the right skill on its own.
Agent0 already knows how to query spans, build a PromQL query, or create a dashboard. What it could not know is how your team works: the runbook you follow when checkout latency climbs, how your environments and datasets are named, what to check first for a problem you have seen before. Until now that context lived in your head, and you retyped it every time.
Now an admin can write it down once. In Organization Settings > Agent0 > Skills, add a custom skill with a name, a description of when Agent0 should use it, and the instructions to follow. Everyone in your organization can then invoke it by typing / in a chat, and Agent0 also reaches for a skill on its own when its description matches the request.
SignalControl, now in every Dash0 account, filters, samples, and aggregates telemetry before anything is stored, so storage is billed only on what you keep.
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.
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.
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.
See the documentation to get started with SignalControl.
Dash0’s Google Cloud integration now lets you filter the resources to monitor and select individual metrics to collect. Coverage also expands to Google Kubernetes Engine, Memorystore for Redis, and Compute Engine VMs.
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.
Choose your resource. Pick your metrics.
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.
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.
Available Dash0 plugins for Coding Harnesses (Claude Code, Cursor, Codex, GitHub Copilot CLI) are now available for Windows.
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.
Message @dash0 directly to chat with Agent0 in a private thread. Your DMs carry their own organization and dataset, so you can ask about data your teammates do not work in without posting it in a shared channel.
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, so you can chart it, alert on it, and group it by metric name or by any resource attribute.
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):
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:
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.
Every Dash0 alert in Slack now has a Fix this in thread button. One click asks Agent0 to explain the failing check, and the answer lands in the alert's own thread.
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.
The Dash0 CLI now manages the whole lifecycle of your assets with the new, experimental apply --since option, which deletes assets based on Git history.
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.
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.
Dash0 now connects to GitLab, on gitlab.com or a self-managed instance. Agent0 reads the diffs, issues and pipelines behind your telemetry, so an investigation is grounded in the code that actually changed, and it can open a merge request when you ask. It works through your own GitLab account, so it reaches only what you can reach.
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.
Setup takes two steps. An admin adds the GitLab connector under Settings → Integrations and connects the organization, then every member connects their own account.
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.
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.
Mention @dash0 in a Slack channel to chat with Agent0 in the thread. It investigates alerts, finds your logs, builds dashboards and checks, and opens a PR with the fix.
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.
But how do you create these deployment events when you use Terraform? terraform apply is often the exact moment a deployment happens, but marking that moment in Dash0 used to mean stepping outside Terraform: the CLI, a CI step, a webhook. The dash0_deployment_event and dash0_log_event actions, introduced in the Terraform provider for Dash0 v1.16.0, close that gap.
markdown
deployment.hcl
1234567891011121314151617181920
resource "kubernetes_deployment" "checkout_api" {
# ... deployment configuration ...
lifecycle {
action_trigger {
events = [after_create, after_update]
actions = [action.dash0_deployment_event.release]
}
}
}
action "dash0_deployment_event" "release" {
config {
service_name = "checkout-api"
service_version = var.image_tag
deployment_environment_name = "production"
deployment_status = "succeeded"
dataset = "production"
}
}
dash0_deployment_event sends a dash0.deployment event that shows up as a dashboard annotation, so "what changed right before this graph moved?" has an answer.
dash0_log_event is its general-purpose sibling: send an arbitrary log event, mirroring the dash0 logs send CLI command.
Both need Terraform 1.14 or later and the provider's new otlp_url attribute (or DASH0_OTLP_URL), which points at the OTLP ingress endpoint rather than the API.
