Dash0 Raises $110M Series B at $1B Valuation
Apr 9, 2026
Chart legends now behave the same way everywhere in Dash0.
Click a legend entry to isolate that series — all other series are hidden so you can focus on the one that matters. Shift+click to select multiple series and build the exact comparison you need. Click the isolated entry again to restore all series.
This interaction model is now applied consistently across all charts in Dash0: dashboards, explorers, and detail views. No more guessing which legend behavior you will get.
Apr 2, 2026
When a check fails, the first thing you want to do is understand why. Until now, drilling down from a failed check into the underlying telemetry meant losing context — metric filters weren't carried over, and the charts you landed on showed largely unfiltered data, often not relevant for your investigation. Dash0 now provides a seamless drilldown experience from failed checks directly into the relevant spans, logs, web events, and metrics — with filters automatically extracted from the check's PromQL expression.
When you open a failed check's details view, Dash0 analyzes the PromQL expression behind the check and extracts the metric names and label filters. The drilldown then uses these filters to show you only the telemetry that matters:
dash0.spans or dash0.spans.duration), with extracted filters pre-applied for a precise view.Not every filter from a PromQL expression can always be mapped to a telemetry query — Dash0 applies what it can and skips what it can't, so you always get the most relevant view possible. Although, the only times we need to skip some of the filters are for the most complex PromQL queries. (If you want to know more, hit Michele up and prepare for an entire discussion about symbolic model-checking on the PromQL AST. It is great fun!)
The following PromQL query:
(sum(increase({otel_metric_name="dash0.spans", otel_span_status_code="ERROR"}[5m])) * histogram_quantile(0.95, sum by(le) (rate({otel_metric_name="dash0.spans.duration", otel_span_status_code="ERROR"}[5m])))) / (sum(increase({otel_metric_name="dash0.logs", otel_log_severity_range="ERROR", service_name="checkoutservice"}[5m])) + 1)
Error span processing time per error log in the checkout service
The metric shows how much error span processing time (at P95) occurs for each error log generated by the checkout service. This is useful for:
When looking at the Failed Check Details page for an alert using this query:
ERROR, across all servicesERROR for the checkoutservice.Now, we could have picked a simpler PromQL expression, but where's the fun in that. You would have looked at it, assumed it just extracted somehow the filters from the timeseries, and phoned it in. In reality, the algorithm does a lot of work with binary operators (+, -, *, /), logic operators (AND, OR, UNLESS), and more.
Open the Failed Checks page, select a failed check, and explore the drilldown cards. Brush a time range in the timeline chart to jump directly into the relevant telemetry.
The lion's share of the research that led to this breakthrough has been performed in collaboration with Julius Volz (who else to rely upon to know all the dark corners of PromQL?!?).
Julius' course about "Understanding PromQL" is a rite of passage for technical staff at Dash0, and we cannot endorse it enough!
Apr 1, 2026
The Query Builder just got a major upgrade. We've unified it with the dashboard panel editor, giving you a cleaner, more consistent experience, and a few quality-of-life fixes along the way.
If you've used both the Query Builder and the dashboard panel editor, you may have noticed they were starting to feel like two different products. Different layouts, different behaviors, different quirks. We've fixed that.
The Query Builder now uses the same interface as the dashboard panel editor. This means a more consistent experience across Dash0, and as we add new widget types to dashboards, they'll automatically be available in the Query Builder too.
Mar 30, 2026
Binary operations in PromQL silently drop results when one side of the expression has no matching time series. If you divide requests by capacity, and a new instance hasn't reported capacity yet, that instance vanishes from your chart — no error, no gap, just missing data. This makes dashboards unreliable and alerts blind to exactly the moments that matter most. Dash0 now supports the fill modifier for binary operations, giving you explicit control over what happens when one side of an expression has no match.
It is complicated to troubleshoot why particular PromQL expressions to not return timeseries, and the workarounds with the OR operator have been historically difficult to learn.
Dash0 worked with the Prometheus community to fix these gaps, and we just shipped the result in Dash0.
The fill modifier lets you substitute a default value for missing series in a binary operation. Three variants cover every scenario:
fill(<value>) applies the default to whichever side is missing, e.g.http_requests_total / fill(1) capacity_totalfill_left(<value>) substitutes only when the left-hand side has no match:(vector(0) > 1) / fill_left(0) requests_total (the left side is always empty, and the fill operator handles it)fill_right(<value>) substitutes only when the right-hand side has no match: requests_total / fill_right(1) (vector(0) > 1) (the right side is always empty, and the fill operator handles it)Notice that, however, when both sides of an operator are missing, no time series is generated.
(We did wonder if the fill behaviour should have been the default, using fill(0) for addition and subtraction, fill(1) for multiplication, and fill_right(1) for division, but that would have been a breaking change for the Prometheus community.)
The fill operator is now available via the UI and the API in Dash0. Enjoy :-)
For a detailed walkthrough of the problem and the fill solution, see the excellent Filling in Missing Series in Binary Operator Matching blog from PromLabs.
We cannot recommend enough the Understanding PromQL course by PromLabs. Taking that course is effectively a right of passage for Dash0 engineers and product people :-)
Mar 30, 2026
Span events are being deprecated in OpenTelemetry. With one click, you can transform them into logs in Dash0.
OpenTelemetry is deprecating span events in favour of log records linked with trace context. Given just how many times we are asked "Should it be a span event or a log record?" by our customers, we are overjoyed at this streamlining in OpenTelemetry.
Span events exist because, in the beginning of the OpenTelemetry project, tackling logs as a separate signal felt like trying to bite off too much. But events like uncaught exceptions were still needed in the model, and so span events were introduced.
Now that logs in OpenTelemetry are stable in terms of specification, and implementation is complete or well underway in pretty much all SDKs, span events are no longer necessary. But, realistically, instrumentations generating span events will remain in use for a considerable time.
To help you with the transition, we have introduced an opt-in, per-dataset option to automatically convert span events into correlated log records during ingestion.
The resulting log records have the correct trace context on them, and "just work" the way you would expect. And in order for you to find out how many span events have been converted to logs, we add to the latter the dash0.span_event.converted = true log attribute.
That is, you do not need to modify your instrumentation, we just "fix your telemetry" for you. (But if you do want to fix your instrumentation, these agent skills we published a few weeks ago can help with the migration!)
Opting in to converting span events to logs will also hide the "Span events" column in your "All spans" Tracing view, but if you want, you can "bring it back" adding the Span event column to a custom view.
Span events and log records have always been equivalent in terms of pricing, as we saw this transition coming a long way.
The only effect on your bill is that the amount for "Spans and span events" will decrease by the same amount that "Logs" increases, based on how many span events you send.
Investigating a single log record rarely tells the full story. The new Related Logs tab surfaces the surrounding context — every log from the same resource and trace, organized chronologically around the record you're inspecting — so you can reconstruct what happened without leaving the sidebar.
Open any log record in the sidebar and switch to the Related Logs tab. Dash0 automatically queries a ±30-minute window centered on the active log and displays the results in a scrollable timeline:
The active log is pinned in the center, clearly marked with a THIS LOG badge and a highlighted background. Older logs appear above, newer logs below, each annotated with a relative time offset (e.g. -2m 15s, +50s) so you can instantly gauge how far apart events are. Infinite scroll loads additional records in both directions as you explore, without ever leaving the panel.
Related Logs supports two independent correlation modes that can be combined:
When both are available, toggle each mode on or off with a checkbox to narrow or widen the view. Correlation badges on each log entry make it clear why a record was included.
Mar 23, 2026
Dash0 now supports exporting audit logs to external systems using the OpenTelemetry Protocol (OTLP). Stream organization-level audit events, including user actions, configuration changes, and access activity, to any OTLP-compatible backend, SIEM, or long-term storage system. Built on OpenTelemetry standards, this capability integrates natively with your existing observability and compliance tooling, giving security and platform teams full control over where audit data lives and how long it is retained.
Audit log export is configured in Organization Settings > Integrations. Once enabled, Dash0 continuously streams audit events as structured OpenTelemetry logs to any OTLP-compatible endpoint you specify. Each audit log entry includes attributes such as the acting user, the action performed, the affected resource, and a timestamp.
This means you can route audit logs into any system that speaks OTLP: a self-hosted OpenTelemetry Collector for further processing, a compliance-focused long-term storage backend, or simply back into Dash0 itself for correlation with
your operational telemetry.
Rather than building a proprietary webhook or CSV export, we chose OTLP as the export format. This keeps audit data compatible with the same pipelines and tooling you already use for traces, metrics, and logs. No custom parsers, no format translations, no additional agents required. If your infrastructure already ingests OTLP, audit logs slot right in.
The screenshot below shows how the exported audit logs appear as structured log entries inside Dash0.
Mar 22, 2026
AI coding agents are rewriting how teams build and operate software. But most CLIs were designed for humans — with colored tables, interactive prompts, and prose help text that agents struggle to parse reliably. Agent mode makes the Dash0 CLI a first-class tool for AI coding agents, with zero configuration required.
Agent mode transforms five aspects of the CLI for machine consumption:
list, get, query, etc.) return JSON instead of tables, without needing the -o json flag.--help flag returns a JSON object with command metadata, flags, subcommands, and usage patterns, so agents can discover capabilities programmatically.stderr, with separate error and hint fields that agents can parse and act on.--force flag were passed.--color none flag, so output is clean for downstream parsing.Agent mode auto-activates when it detects a known AI agent environment variable. It recognizes Claude Code, Cursor, Windsurf, Cline, Aider, GitHub Copilot, OpenAI Codex, and any MCP server session.
For explicit control, enable it with the --agent-mode flag or the DASH0_AGENT_MODE=true environment variable, and DASH0_AGENT_MODE=false to override and disable.
When an AI coding agent queries your dashboards, investigates error logs, or applies asset definitions, it needs structured, predictable output — not tables padded for terminal width. Agent mode removes that friction. The CLI becomes a tool that agents can drive as naturally as a human types commands, with every response machine-readable by default.
Combined with the comprehensive command reference, consistent naming conventions, and profile-based authentication, the Dash0 CLI is designed to be the interface between your AI coding agent and your observability platform.
Mar 21, 2026
The Dash0 Terraform Provider is now also available on the OpenTofu registry.
That's it. That's the post.
Mar 18, 2026
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.
