Recent changes and improvements to Dash0

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

Until now, to stop the alerts of a known problem, you had to change or disable the check rule. That edited the rule and broke its history.

Now you can silence a failed check:

• Silence from the failed check. Open a failed check, click Silence, and choose how long. Add a reason so your team knows why. A silence lasts up to 7 days.
• See what is silenced. The failed checks list has a Silenced column. A failed check shows which silences cover it and when they end. Its timeline shows the periods when it was silenced.
• Track, extend and end silences in the Silences Hub. The Silences Hub in Settings lists the active and completed silences of the current dataset, with the scope, reason, schedule and creator. Extend a silence, or Unsilence it to end it early.
• Ask Agent0. In a chat, Agent0 can list your silences, propose a new silence or a change to one, and end silences.

Failed Check automations still run. Each one can include, exclude or only use silenced checks. Failed Check Notification automations do not run while a check is silenced.

A new silence can take up to 3 minutes to take effect.

Read the docs: Silence Failed Checks

Until now, a custom skill belonged to the whole organization. Only admins could write or change one, and every member got it. A skill only one team needed still reached everyone.

Now you choose who gets each skill:

• Share with your team. Share a skill with members, teams, or the Admin and Member roles, at Read or Edit. Read lets people use the skill. Edit also lets them change, share, and delete it. Anyone without access does not see it.
• Admins keep access to every skill. Admins have Edit on every skill, so no skill gets locked away. On a skill managed through the API or Terraform, admins can view and delete it instead. Nobody can remove this access.
• Shared skills start off. This is deliberate: nobody finds a new skill in their Agent0 runs without choosing it, so your agent flows stay consistent. Each person turns it on with Enabled for you on the Skills tab.
• Turn a skill on for a team. Switch on Enabled next to the team's entry when you share the skill. Admins can do this for anyone, members for themselves and their own teams.
• Members create skills too. Besides admins, all members can now create custom skills and share them within their organization.
• See who created a skill. The Skills tab shows the creator of each skill.

Check your automations. Automations now use only the custom skills you allow. Existing automations start with no allowed skills, so open each automation that uses a custom skill and add it under Tools & Skills.

Read the docs: Control Skill Sharing and Access and Allowed Skills

Billing & Plans now breaks down your organization's Agent0 credit spend for each billing period.

Group credits by source (people, automations, evals and API tokens), by individual consumer, by model level or by dataset, and filter by any of them. Cost and credits follow whatever you've filtered, and each row links to where you manage that member, automation, eval or token. When spend jumps, you can find what's behind it and open it from there.

If you've set an Agent0 cap, you also see how much of it this period has used and where you'll end up at the current pace.

The breakdown covers credits spent from October 5, 2026.

See Billing & Plans for details.