Visualize the full topology of your distributed traces, dependencies, cross-boundary interactions, and service relationships, for faster root cause analysis.
The Trace Graph is a new view in Dash0 that transforms a trace into a functional architecture diagram. Each node represents a service or resource involved in the trace, connected by edges that show how they invoke one another, including asynchronous relationships across span links.
The Waterfall and Flame Graph are great for drilling into latency and execution details, but they make it hard to see the big picture. The Trace Graph shows you how your system actually behaved during a request: which services called which, where errors propagated, and how independent flows connected. It's the fastest way to understand the shape of a trace before diving into the details.
When you change an operator in an existing filter, Dash0 keeps your selected values intact whenever they're compatible with the new operator. Switch from "is" to "is not"? Your values carry over. Change from "is one of" to "is not one of"? Same thing. Going from a multi-select operator to a single-value operator like "contains" works too, as long as you only had one value selected.
A small change, but one less thing interrupting your flow when building filters.
AI coding agents are transforming how teams write code, but they have a blind spot: observability.
When an agent scaffolds a new service or adds a feature, it rarely sets up instrumentation — and when it does, the result is often noisy, non-standard telemetry that obscures more than it reveals.
Dash0 Agent Skills close that gap.
Dash0 Agent Skills are packaged instructions that plug into any agent that supports the Agent Skills format — including Claude Code, Cursor, and Windsurf — and give it the knowledge to emit high-quality, cost-efficient OpenTelemetry telemetry from the start or to fix existing setups. All of it is guidance that will serve you well with any OpenTelemetery-based observability setup, grounded in semantic conventions and present and (soon-to-be) future best practices in OpenTelemetry.
Once installed, the skills activate automatically whenever the agent works on a relevant task: instrumenting application code, configuring a Collector pipeline, choosing span attributes, or writing OTTL expressions.
otel-instrumentation: Expert guidance for emitting traces, metrics, and logs across 10 languages and frameworks: Node.js, Go, Python, Java, Scala, .NET, Ruby, PHP, Browser, and Next.js. The agent learns when to use which signal, how to set resource attributes, how to handle errors and span status, and how to keep cardinality under control. Kubernetes-specific guidance covers the Downward API, environment variables, and pod-spec configuration.
otel-collector: Everything the agent needs to configure and deploy the OpenTelemetry Collector: receivers, processors, exporters, and pipelines. Covers agent-vs-gateway deployment patterns, memory limiting, batching, tail sampling, RED metrics, and four deployment methods — raw manifests, the Collector Helm chart, the OpenTelemetry Operator, and the Dash0 Operator.
otel-semantic-conventions: A decision framework for selecting, placing, and reviewing OpenTelemetry semantic convention attributes. The agent searches the Attribute Registry before inventing custom attributes, places them at the correct telemetry level, and flags common mistakes like high-cardinality metric dimensions.
otel-ottl: Guidance for writing OpenTelemetry Transformation Language expressions for the Collector's transform, filter, and routing processors. Covers syntax, contexts, converters, path expressions, and common patterns like sensitive-data redaction and attribute enrichment.
Every rule is written so that an agent can act on it without human interpretation. Decisions are enumerable — lookup tables and explicit criteria replace open-ended advice. Code examples accompany every actionable rule, showing both the correct pattern and the anti-pattern.
Install the skills, open your agent, and ask it to add OpenTelemetry instrumentation to your app. The agent handles the rest: correct resource attributes, set span status code and message properly, the right metric instrument type, a Collector pipeline that actually works, and so much more.
Monitor the complete Kubernetes cluster with one command
The Dash0 Kubernetes operator just became much more powerful. Previously, you had to enable monitoring separately for each namespace. Now you can let the Dash0 operator automate this! This is very useful if you want to monitor all namespaces in your cluster. It is also useful if you create new namespaces frequently and want to have them monitored right away, without additional setup.
Auth tokens already support restricting ingestion to specific datasets. Now, tokens can also be restricted to individual signal types — logs, spans, metrics, profiles, or web events — giving you fine-grained control over what data each token is allowed to send.
When creating or editing an auth token in Settings > Auth Tokens, a new Signal type dropdown appears between the dataset restriction and permissions fields. Select a signal type to lock the token to that single type of telemetry, or leave it set to "Unrestricted" to accept all signals as before. The restriction is enforced server-side in the collector pipeline: any data that does not match the permitted signal type is silently dropped.
Website monitoring in Dash0 is powered by the Dash0 Web SDK, which sends both spans and logs over the same OTLP connection. In backend observability, each signal type typically arrives through a separate pipeline with its own token. But the browser is different — a single Web SDK instance emits page loads, web vitals, user interactions (as spans), and console errors or custom events (as logs) through one shared auth token.
With signal type restrictions, you can now issue a dedicated token that only accepts web events. This is valuable for two reasons:
1. Security boundary. The auth token embedded in your website's JavaScript is publicly visible to anyone who opens the browser's developer tools. A token restricted to web events cannot be abused to ingest backend traces, metrics, or profiles into your organization — even if it is extracted from the page source. 2. Blast-radius reduction. If a web-events-only token is compromised or accidentally shared, the damage is contained to a single signal type. Backend observability data, alerting metrics, and profiling data remain unaffected.
Signal type restrictions combine with the existing dataset restriction — a token can be scoped to both a specific dataset and a specific signal type for maximum isolation.
And, by the way, you can go and retrofit your existing authentication tokens with the new restrictions!
When investigating issues in production, the first question is almost always "what's different about the errors?" Until now, the Triage panel in
the Trace Explorer, Logs Explorer, and Web Events Explorer defaulted to comparing against the current timeframe — a useful but generic baseline
that required an extra click to switch to error comparison.
Starting today, all three explorers default to error comparison mode. The triage panel immediately highlights which attributes correlate with
errors, so you can jump straight into root-cause analysis without changing any settings.
Error comparison as the default baseline. Opening the Triage tab in the Trace Explorer, Logs Explorer, or Web Events Explorer now automatically compares error spans, error logs, or failed web events against their non-error counterparts. There is no longer a need to manually switch the analysis method.
Conflicting filter detection. If you already have a general filter restricting data to errors (e.g., otel.span.status.code = ERROR), the error comparison becomes meaningless — every record matches both the selection and the baseline. When this happens, the triage panel now detects the conflict and shows a "Remove filter" button that strips the redundant filter in one click, restoring a meaningful comparison.
Error triage is the most common entry point when investigating incidents. Defaulting to error comparison mode removes a step from the most frequent workflow, while the new conflicting-filter detection ensures users are never stuck on a "No major differences" screen without guidance on how to fix it.
The translation works automatically as long as your JavaScript files and source maps are reachable via HTTP(S).
If your build tool generates source maps and deploys them alongside your JavaScript bundles, no additional configuration is required.
If your source maps are hosted behind authentication, you can configure a Source Map Integration to provide credentials (Basic Auth, Bearer token, or custom headers) for specific URL prefixes.
What’s included:
Automatic translation of minified JavaScript stack traces
Support for public and authenticated source maps
URL prefix–based integration configuration
Per-frame translation with detailed error feedback
Original stack trace always preserved
Each frame in a stack trace is translated independently. If a frame cannot be resolved, it remains in its original form and shows a warning icon. Hovering over the icon reveals the reason (for example, missing source map, authentication error, or file not found).
You can switch between the original and translated stack trace at any time using the toggle in the UI.
Every metric, attribute, and event that Dash0 adds to your telemetry is now defined in a public, machine-readable registry. The Dash0 Semantic Conventions give you a single place to look up what each field means, where it comes from, and how to query it.
At Dash0, we live and breathe OpenTelemetry Semantic Conventions. And in building Dash0, we have defined attributes we add to telemetry you send us, and metrics we make available to you out of the box like the synthetic metrics that you use a lot for alerting.
We like a lot of what we see in the OpenTelemetry Weaver project, which provides the tooling that the OpenTelemetry project uses to publish the OpenTelemetry Semantic Conventions.
Dash0 enriches incoming telemetry with attributes such as dash0.operation.name, dash0.resource.type, or dash0.log.pattern. Until now, the meaning of these fields lived in internal documentation. Making them public means you can discover every Dash0-specific attribute, metric, and event in one place. And chances are, you may discover the next Dash0 feature you love!
Every attribute Dash0 materialises on spans, logs, metrics, and web events is documented — from resource identity (dash0.resource.id, dash0.resource.name and dash0.resource.type) to AI-inferred log fields (dash0.log.ai.message_inferred).
Also OTLP protocol fields that Dash0 maps to queryable attributes (otel.trace.id, otel.span.kind, otel.log.severity.range, and many others) are included as well.
All dash0.* metrics are listed with their instrument, unit, and stability level. Synthetic metrics like dash0.spans and dash0.spans.duration are clearly marked, along with their deprecated Prometheus aliases.
The registry also covers website monitoring (dash0.web.*), synthetic checks (dash0.synthetic_check.*), alerting (dash0.check.*), and so on.
The dash0.deployment event — that you can emit from CI/CD pipelines to mark a service deployment (for example using the brand new Dash0 CLI) is fully specified, including its required resource attributes and optional VCS metadata.
Every metric and attribute page includes an Open in Dash0 link that takes you straight to the relevant explorer with the right filters pre-applied. Click a metric name to open it in the Metrics Explorer. Click an attribute to jump to the Traces, Logs, Metrics, or Web Events Explorer with the right filters pre-set.
Agent0 now integrates with Linear, bridging project management and observability to bring issue context directly into debugging and investigation workflows in Dash0.
Linear integration for Agent0: Agent0 can now reference Linear issues, projects, and teams while investigating production behavior, so you can tie runtime signals to the work your team already tracks.
Invoke Agent0 from Linear: Mention @Dash0 in any Linear issue or comment to start an investigation without leaving Linear. Agent0 reads the issue context, runs analysis against your telemetry, and posts results back into the same thread, including tool execution steps and a deep link to the full session in Dash0.
Context preserved across tools: Agent0 responses posted into Linear include a deep link that reopens the investigation in Dash0 with organization, dataset, and time range already set.
Read-only access: Agent0 reads your Linear workspace but cannot create, modify, or close issues.
Admins can now mark any dataset as preferred for the organization. Dash0 opens the preferred dataset by default for all members of the organization unless a different dataset is specified in the URL or if they previously visited a different dataset.
Preferred dataset: Enable the Preferred toggle on any dataset's Overview page. Dash0 opens that dataset for all organization members when no dataset is encoded in the URL.
Note that if users already opened a dataset before, that previously stored dataset has precedence over the preferred organisation dataset.
Available to all Dash0 users. Changing the preferred dataset requires admin permissions.
