Recent changes and improvements to Dash0

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.

AI SDLC Insights now supports GitLab, so you can see how AI-assisted merge requests move through review and merge.

Connect GitLab, choose the groups to watch, and select which Dash0 datasets receive their repository data. Merge requests appear with their author, state, reviewers, and linked AI coding sessions, with links back to GitLab.

See the GitLab integration overview and follow the setup guide to connect your instance.

A stack trace tells you an error was thrown. It does not tell you that the user clicked Submit four times because the button never gave feedback, or that a half-rendered modal was sitting over the page. You had to reconstruct that from the event list and guess at the rest.

Session replay records the DOM instead. Load the recorder in the Dash0 Web SDK, and the Websites session view plays the session back above its event table.

Turning it on. The recorder is a separate, opt-in bundle of about 22 KB gzipped. It is never part of your main SDK bundle, and nothing is recorded until you load it. Pass it to init, import it lazily, or add a second script tag:

import { init } from "@dash0/sdk-web";
import { recorder } from "@dash0/sdk-web/session-recording";

init({
  serviceName: "my-website",
  endpoint: { url: "REPLACE THIS", authToken: "REPLACE THIS" },
  sessionRecording: { recorder },
});

What leaves the browser. Every visible input, textarea and select is masked by default. Give an element the dash0-mask class to replace its text with asterisks, or dash0-block to keep it out of the recording entirely and leave a placeholder of the same size in the replay. Only the visible document is recorded, so a background tab records nothing, and sessionRecording.samplingRate decides what share of sessions you keep.

What you can watch. The whole browser session, tab switches included. The scrub track marks JavaScript errors, rage clicks, and tab switches, and hovering a segment names the tab and page it covers. The page view list and the event table follow the playhead, so the row you are reading is the moment you are watching, and an HTTP request in that table still opens View full trace into the backend trace it started. Playback starts on the first snapshot rather than waiting for the download to finish.

Sessions that have a replay are marked in the sessions list and in the web events explorer, and View full session on any event opens the replay at that event.

Read the docs to record your first session: Web SDK Setup. For what a replay shows you once you have one, see Watch a Session Replay.

Until now, you found out that a notification channel was broken during an incident, often because your customers noticed something your alerts didn't manage to tell you. Now Dash0 tracks the result of every alert delivery it sends to a notification channel, and each channel shows a delivery status. When a channel has a problem, admins see a marker on Notification Channels in the Settings menu. The channel shows a banner that explains what went wrong and how to fix it. After the fix, click Send test notification to confirm that alerts arrive again.

Read the docs: Monitor Notification Channel Delivery