Recent changes and improvements to Dash0

Coding agents made writing a change cheap. Reviewing it did not get cheaper, so pull requests wait for a person, including the routine ones nobody needed to read line by line.

AutoMerge, now in public beta in Darkplane, takes that routine share off your reviewers. AI evaluators score each pull request against criteria you define. Each criterion returns a score from 0 to 100 with a rationale. When the weighted score reaches your threshold and no criterion falls below its floor, AutoMerge approves. Everything else goes to a person.

Every repository starts with three criteria: blast radius, evidence quality, and change footprint. Treat them as a starting point and fit them to your repository:

• Add the questions your reviewers ask, and remove the ones that don't fit.
• Write the prompt each evaluator follows, and choose the tools it may use to read the repository and the pull request.
• Weight the criteria by what matters most, and set a floor that rejects a pull request on one criterion alone.
• Tell the evaluators what the code doesn't show, such as which directories carry the highest consequences.

You decide how much it may do

Each repository runs in one of four modes: Off, Dry run, Auto-approve, or Auto-merge. Path rules give specific paths their own level. Mark migrations, infrastructure, or billing as Protected, and a pull request that touches them goes to a person without being scored. A pull request always runs at the least autonomous level of any file it touches.

AutoMerge fails closed. If a criterion can't produce a score, nothing is approved. It doesn't approve a commit whose CI is failing, and it never approves a pull request again after a reviewer dismissed its approval. Its check is advisory, so it blocks no merge unless you make it a required check in GitHub.

Start in Dry run

In Dry run, AutoMerge comments its decision on each pull request and approves or merges nothing. Dash0 grades every decision against what your reviewers did next and shows the result as Agreement with humans. Once its decisions match your reviewers, switch the repository to Auto-approve. Before you change criteria or the threshold, test the change against past pull requests on the Testing tab.

AutoMerge works with repositories connected through the GitHub integration. Read Set Up AutoMerge to start your first Dry run, or see the AutoMerge overview.

Until now, when Agent0 wrote a check rule or an automation, it put the definition in the chat. Each change was another block of text, and nothing told you which one was current or whether it was already created.

Now Agent0 proposes changes as artifacts:

• One card per change. Each proposal is a card in Agent0, in the full-page chat or the side panel you open next to any page. When Agent0 revises it, the card gets a new version instead of a new block.
• You decide what changes. In a conversation, Agent0 does not change anything in Dash0 on its own. Click Create or Update on the card to apply it, in Dash0 or in Slack. Automations still act on their own, within the tools you allow them.
• Preview before you apply. Preview opens the proposal in its usual editor, with the chat alongside.
• No silent overwrites. If someone changed the entity after Agent0 read it, the update is refused. Ask Agent0 to redo its proposal against the latest version.
• Everything in one place. The Artifacts tab in the Agent0 sidebar lists every artifact in the conversation.
• Change several dashboard panels at once. On a dashboard, hold Shift+Cmd (Shift+Ctrl on Windows and Linux) and click panels to add them to Agent0's context, then ask Agent0 to change them. The card lists the panels each revision added, removed or edited.

Artifacts are available today for dashboards, check rules, SLOs, synthetic checks, automations, silences, recording rules and custom skills, with more types on the way.

Read the docs: Use Agent0

Custom skills hold the procedures only your team knows, but until now they could only be written in Dash0. A change to a skill had no review, no history, and no way to roll it out the same way to every organization.

You can now define a custom skill as a Dash0Skill YAML document, keep its SKILL.md and supporting files in Git, and apply them with the Dash0 Terraform provider or the Dash0 CLI.

How it works

A skill is identified by its dash0.com/origin: Dash0 creates it the first time and updates it after that. Custom skills belong to the organization, so no dataset is needed. The spec.permissions list sets who can use the skill, and defaultEnabled: false ships it turned off.

A skill managed by Terraform can be read and deleted in Dash0, but only your configuration changes its content.

Dash0 Terraform provider

Since v1.23.0:

custom-skill.tfresource "dash0_custom_skill" "incident_response" {
  custom_skill_yaml = file("${path.module}/skills/incident-response.yaml")
}

Adopt a skill you already have with terraform import dash0_custom_skill.incident_response <origin-or-id>.

Dash0 CLI

Since v1.20.0:

custom-skills-cli.sh# Create or update a skill from a YAML file
dash0 apply -f incident-response.yaml

# List skills, and export one ready to edit and apply again
dash0 -X agent0 skills list -o wide
dash0 -X agent0 skills get <origin-or-id> -o yaml

Read the docs: Manage Agent0 Skills as Code

A blank eval form asks a lot. You have to know which spans to judge, how many to sample, which model should judge them, and how to write a rubric it applies the same way every time. Most teams know what worries them, like hallucinations or users getting fed up, but not how to turn that into a prompt.

Eval templates give you the prompt. Click Create new on the Evals page to open the catalog, pick a template, and the eval editor opens with everything filled in.

What's in the catalog. 28 templates in five categories, from Hallucination and Tool selection to User frustration and PII leakage. Top picks gives you a place to start.

What a template fills in. Everything the eval form asks for: span filters, a 20% sample rate, the judge model and prompts, and the output type. Each system prompt spells out what counts and what doesn't. The Hallucination judge, for example, doesn't count a clarifying question or a faithful summary of the context as a hallucination. Change whatever doesn't fit your agents, then save.

What you end up with. An ordinary eval. Edit, disable, or delete it like one you wrote yourself. A later change to the template never changes your eval, so its scores stay comparable over time.

Read Eval Templates to see every template and how to start from one.

Telemetry tells Agent0 that a pod was OOM-killed, that a rollout is stuck, or that a service stopped receiving traffic. It does not tell Agent0 why. The answer is often in the cluster itself: a memory limit that is too low, a readiness probe that times out too early, a service selector that matches nothing, a network policy that drops the traffic. Until now, finding that meant switching to a terminal, running kubectl yourself, and pasting the output into the chat.

With the Agent0 Kubernetes integration provided by the Dash0 Operator, Agent0 can look for itself. During an investigation, it reads the state of your cluster, the same way you would, and connects what it finds with your logs, metrics and traces. It can inspect namespaces that send no telemetry yet, work across several clusters in a single investigation.

Agent0 finds the Service selector mismatch via kubectl.

Read-only, and you stay in control

Agent0 can look, but never touch. The integration only allows reading, so Agent0 cannot change, restart or delete anything in your cluster, and it never gets a shell into your containers. Secrets are off limits, and credentials are removed from every response before it leaves your cluster. You decide which resources Agent0 may see, and you can narrow or widen that at any time.

The connection is established from inside your cluster. There is no need to expose your Kubernetes API server, open a firewall port, or hand any cluster credentials to Dash0.

Opt in when you are ready

The integration is disabled by default. Nothing changes in your cluster until you explicitly turn it on in the Dash0 Operator (version 0.159.0 or later).

Not using the Dash0 Operator to collect telemetry? You can run it just for the Agent0 Kubernetes integration, alongside whatever you already use to send telemetry to Dash0.

Read the documentation to connect your first cluster.

Dash0's AI SDLC Insights now supports Amp, giving teams more complete visibility into AI coding activity across their development tools.

With this new integration, AI coding sessions from Amp, locally and in Orbs, are included in Dash0's cost tracking, developer adoption metrics, and AI-assisted pull request analysis. Whether your team uses Claude Code, Cursor, Codex, GitHub Copilot, OpenCode, or Amp, you can track AI usage and its impact in one place.

To get started, install and configure the Dash0 plugin for Amp from the Dash0 agent plugin repository, then start an Amp session.

Check out the Integration Hub for detailed setup instructions for Amp.

Until now, Dash0 teams lived apart from your identity provider. When someone joined or left a group in your directory, an admin had to repeat the change in Dash0, and the dataset access you granted through teams drifted from who actually belonged to each team.

Dash0 now turns the groups in your identity provider into Dash0 teams and keeps their membership in sync.

Turning it on. If your organization has an enterprise connection with SSO and Directory Sync, an admin can enable team sync. You see every group and its members before any team is created, and the teams appear within a few minutes.

What stays in sync. People who join or leave a group join or leave the matching team as soon as your identity provider sends the change. This includes people who have not signed in to Dash0 yet. A renamed group renames its team.

What it changes. Each group becomes a new team, and teams you already have in Dash0 keep their own members. The sync manages membership only, so you grant dataset access to synced teams as you would to any other team. A deprovisioned user leaves every synced team but stays in your organization until you remove them.

Once Dash0 enables self-service SSO for your organization, you set up SSO and Directory Sync yourself.

Read the docs: Team Sync from SCIM Groups

The Dash0 Operator has supported zero-touch auto-instrumentation for .NET workloads for a while, via the upstream OpenTelemetry .NET Instrumentation, which currently supports .NET 8+.

However, upstream support will soon be restricted to .NET 10 and 11 only, as .NET 8 and 9 will join 6 and 7 in end of life (EOL) in November 2026.

From our vantage point, we see that the industry has not yet moved away from .NET 6 through 9, so those workloads should not stop being observable.

How do you try it?

To enable it, upgrade the Dash0 Operator for Kubernetes to v0.159.0 or later.

An error tells you something broke. Most of the time when a user gets stuck, nothing breaks: a button gives no feedback, so they click it again, and again, and leave. Your error tracking stays quiet, and you only hear about it if someone files a ticket.

The Dash0 Web SDK now flags that moment as a rage click: three or more clicks on the same spot, each within a second of the last.

Turning it on. Nothing to do. Rage clicks are detected in every session the SDK records, so each one comes with the replay that shows it. Sessions without a replay have no rage clicks. If three clicks in a second is too eager or too strict for your website, change it in the Web SDK configuration.

Finding them. Filter your sessions by rage clicks to list every session where a user got stuck. Each rage click is marked in the replay, so you can jump straight to the moment and see what the page did, or did not do.

What leaves the browser. Where the clicks landed, on which page and element, how many there were and how fast, and the element's label, such as "Place order". For form fields, the label is the field's name, never what the user typed. Anything you mask or block sends no label.

Read Watch a Session Replay to find and watch sessions with rage clicks. For everything a rage click carries, see Understand Web Event Types.

Until now, every Agent0 investigation started from scratch. Agent0 now keeps a memory when it learns something worth knowing next time: the cause behind an alert that keeps firing, a dependency your telemetry does not show, or a service that throws harmless errors during its nightly batch job. When a similar symptom comes up later, Agent0 finds the memory and starts from what it already knows.

Memory works everywhere Agent0 does: in Chat, in automation runs, in Slack, in Linear, and over MCP.

Shared when it helps everyone

Your memories are yours. When Agent0 learns something in your chats that it judges useful to your whole organization and free of anything private, it shares the memory, so your teammates' investigations get it too. You can share or stop sharing any memory yourself, or turn auto-sharing off in Settings → Agent0. Organization admins can delete a shared memory that no longer applies. An automation's memories stay with that automation and help its later runs.

You stay in control

The new Knowledge → Memories page lists what Agent0 remembers for you and what your teammates shared. Each memory links back to the thread or automation run that saved it and shows how often Agent0 read it. Edit a memory when it is wrong, or delete it when it no longer applies. A thread's Chat Details show which memories Agent0 saved and read while answering, and the new Knowledge tab on services and resources shows what Agent0 remembers about them.

Memories stay in your organization and never train a model. A memory is a note Agent0 reads back when it is relevant.

See About Memory for details.

Until now, a signal-to-metrics rule produced one fixed metric: a duration histogram for spans, or a count for logs. A number that lived in an attribute, such as a response size or a queue depth, stayed in the raw records, and charting it meant querying them.

Now a rule's Metric type can record a value you choose:

• Sum adds up the value from each matching span or log record, or counts the records. Mark it monotonic for values that only go up, such as bytes sent.
• Gauge keeps the last value in each aggregation interval, such as the current depth of a queue.
• Exponential histogram records how the values are distributed, so you can chart percentiles of payload size. A count can weight each value when one record describes a batch.

Pick an attribute in Simple mode, or write an OpenTelemetry Transformation Language (OTTL) expression for anything more involved. Both work for span rules and log rules, in the SignalControl UI and through the API.

Conversion still runs at ingestion, before sampling, so a metric from a span rule counts every matching span, including spans in traces you sample out. Existing rules work as before.

Good to know

• Rules convert telemetry that arrives after you save them. They do not backfill.
• On SignalControl Edge, these metric types need edge collector 1.6.0 or later. Upgrade every edge collector before you create one.

Read the docs: Convert Signals to Metrics

You now have a second way to get CloudWatch metrics into Dash0. Next to Metric Streams, which push metrics through Amazon Data Firehose, Dash0 can now scrape CloudWatch metrics from your AWS account on a regular interval. Both paths produce metrics with the same OpenTelemetry names, so you can choose the one whose trade-offs fit each use case.

Scraping vs. Metric Streams compares the two paths in detail, including AWS costs, and explains how to switch from one to the other without duplicate data.

With scraping:

• Nothing to deploy: connect your account, and Dash0 assumes a read-only role in it.
• Less redundant data: Dash0 queries only the most specific dimension set for each metric and skips the restated totals. That cuts time series on your AWS bill and in Dash0.
• Scrape by tag: in the Metrics tab, use AWS resource tags to choose what to scrape, per namespace or for the whole integration.
• Filter by tag everywhere: the same tags are attached to your resources, so you can filter metrics, logs and traces by them.
• Familiar names: scraped metrics use the same OpenTelemetry names as Metric Streams.

To get started with scraping, set up the AWS integration and turn on the namespaces you need in the Metrics tab.