Your web event annotations now appear as pins right on the GeoMap, so you can see where in the world your users are hitting errors, not just that they are. Plus a new city reference layer and trackpad pinch-to-zoom.
Until now, the GeoMap could color countries by value, but the events behind those numbers (a spike of web errors, a burst of failed requests) lived in a separate timeline with no sense of place. You could see that something happened, but not where your users actually were when it did.
Now your web event annotations show up as pins on the map. They render with the same markers, tooltips, and severity colors you know from the event timeline, placed by the geographic data Dash0 already enriches onto web events. Turn them on from the panel's annotation settings, exactly like you would on a time-series chart, and a regional error pattern that used to be buried in a timeline becomes obvious at a glance.
As you zoom out, nearby pins cluster into a single bubble that grows with the count and takes on the most severe color in the group; zoom back in and they split apart again. Hold Alt/Option to pin a tooltip open so you can click straight through to the underlying events.
The map also reads exact coordinates and locality when your telemetry carries them, so if you instrument other signals (logs, Kubernetes, or service events) with geo data of your own, those land on the map too. The pins resolve from the standard OpenTelemetry geo attributes: https://opentelemetry.io/docs/specs/semconv/registry/attributes/geo/
We shipped two extras alongside it. A new "Show Cities" toggle overlays reference points for major cities and towns, giving you orientation as you pan and zoom below the country level. And on macOS, trackpad pinch-to-zoom now works directly on the map instead of zooming the whole page.
Dash0 now collects metrics for your Cloud SQL instances automatically. Connect a GCP project and see CPU, memory, and disk utilization, connection activity, and engine-specific performance for PostgreSQL, MySQL, and SQL Server, with no dashboards to build.
Automatic metric collection across connected projects. Every Cloud SQL instance in your connected GCP projects appears under Infrastructure > Google Cloud > Cloud SQL. The overview lists each instance with its database engine and version, region and project, CPU, memory, and disk utilization, network throughput, and any open issues raised by failed check rules.
Detailed instance views. Click any instance to drill into time-series charts organized into three sections. Resource utilization covers CPU, memory, and disk gauges, network ingress and egress, disk read and write operations, and storage by data type. Connections and activity tracks connection counts and query throughput. Performance and cache surfaces hit ratios, transaction throughput, and engine health indicators.
Engine-aware metrics. Dash0 detects the database engine from each instance's version and maps it to the OpenTelemetry db.system.name attribute. The connection and performance sections then adapt to that engine: backends, statements, and transaction ID utilization for PostgreSQL; threads, slow queries, and InnoDB buffer pool, row locks, and deadlocks for MySQL; login attempts, blocked processes, deadlocks, buffer cache hit ratio, and page life expectancy for SQL Server.
Query and alert with PromQL. Metrics are stored under their GCP Cloud Monitoring type names and queryable with otel_metric_name in the Query Builder. Build custom dashboards, then create check rules to catch high utilization, disk approaching quota, connection saturation, slow queries, deadlocks, and falling cache hit ratios.
Correlation with application telemetry. Pivot from instance utilization to the traces and logs from the services hitting that instance. When database clients are instrumented with OpenTelemetry, Dash0 correlates their db.system.name and db.namespace spans with Cloud SQL infrastructure metrics so you can tie database pressure to user-facing latency.
To get started, set up the [Google Cloud integration] and open Infrastructure > Google Cloud > Cloud SQL.
Browser-based OAuth login, a local OTLP forwarder for in-loop development, precision-mode queries for exact lookups, and a one-command Homebrew install — all in one release.
OAuth support was the most requested (by a wide margin!) feature request for the dash0 CLI.
dash0 login opens your browser, completes the OAuth 2.0 + PKCE flow, and stores the resulting access and refresh tokens in your profile. Access tokens refresh transparently before they expire. Static auth_* tokens still work, although when you change a profile to use OAuth, the previous access token gets overwritten.
Create an OAuth profile and authenticate:
sh
123
dash0 config profiles create prod --oauth\
--api-url https://api.eu-west-1.aws.dash0.com
dash0 login --profile prod
dash0 config show annotates the auth state, so you always see whether a token is static, OAuth-active (with remaining lifetime), or OAuth-empty:
sh
123
Profile: prod
API URL: https://api.eu-west-1.aws.dash0.com
Auth Token: ...1234567 (OAuth, expires in 14m20)
The dash0 CLI will refresh the authentication token when it expires, using the refresh token, so the actual expiration and refresh of auth tokens will be invisible for you.
When you're done, revoke the refresh token and clear the profile with:
sh
1
dash0 logout--profile prod
Safe by default for AI agents: When Claude Code, Cursor, or another coding agent invokes the CLI, dash0 login refuses to open a browser and dash0 logout requires explicit --force — so an agent cannot silently rotate or revoke a profile's OAuth session. Errors point agents at the recovery paths instead:
sh
1234
$ dash0 logs query
Error: profile "prod" is OAuth-typed but not authenticated.
Hint: set DASH0_AUTH_TOKEN to a static `auth_*` token, or convert the profile with
If you have worked with OpenTelemetry for a long time, you probably have some sort of local OpenTelemetry Collector setup working. But what if we could make it dead simple to send telemetry to Dash0 from your local apps? Enter dash0 otlp proxy.
dash0 -X otlp proxy runs a foreground forwarder on 127.0.0.1:4318 (OTLP/HTTP) and 127.0.0.1:4317 (OTLP/gRPC) — the OpenTelemetry SDK defaults — and ships the telemetry it receives to Dash0 with your active profile's credentials. An SDK at default endpoint configuration connects with zero environment-variable changes.
You will also see the rate at which you are sending data and how much you have sent in total. This should reduce your FUD when trying to get your OTel setup going!
You can also tag forwarded traffic so individual developers can filter their telemetry on a shared backend:
Or watch every forwarded record in the same style as the Collector's debug exporter while you iterate on instrumentation:
sh
1
dash0 -X otlp proxy --tail
Note: The proxy is a local-dev shortcut, not a replacement for the OpenTelemetry Collector — see the docs for the agent-mode event schema and failure-mode classification.
By default the Dash0 API applies adaptive sampling to log and span queries — fast on large datasets, statistically representative for exploration. For narrow lookups that must return every match (a specific trace.id, a test.id from CI, a request ID), pass --precision disabled:
sh
12
dash0 logs query --precision disabled --filter"test.id is 7a3f…"
dash0 spans query --precision disabled --filter"trace.id is 0af7651916cd43dd8448eb211c80319c"
traces get always runs in Precision mode, so a retrieved trace is never missing spans regardless of the query window.
The CLI's Homebrew distribution has moved to a dedicated tap (dash0hq/homebrew-dash0-cli) and switched from a formula to a cask, which is Homebrew's recommended mechanism for pre-built CLI binaries.
New users install with a single command — no brew tap, no brew trust (introduced with Homebrew 6.0):
sh
1
brew install--cask dash0hq/dash0-cli/dash0
Existing users see a deprecation warning on brew upgrade dash0 pointing at the new path. The migration is a one-time three-step procedure:
sh
123
brew uninstall dash0
brew untap dash0hq/dash0-cli
brew install--cask dash0hq/dash0-cli/dash0
Note: We plan to keep supporting the legacy tap as well, but you will need trust to it via Homebrew. Casks are a better way to get your latest dash0 CLI.
See the full migration guide for context on the Homebrew 6.0 tap-trust changes that motivated the move.
All this is available now in Dash0 CLI 1.14.0. Upgrade via Homebrew with brew upgrade --cask dash0 (after migrating from the legacy formula), pull the latest container with docker pull ghcr.io/dash0hq/cli:latest, or download a binary directly from the GitHub release.
OAuth for MCP servers: Connect Agent0 to MCP servers using OAuth instead of manually managing access tokens. Authorize once and Dash0 handles the rest — securely obtaining and storing the credentials Agent0 needs to access the server's tools.
One-click authorization: Starting the OAuth flow is a single click from the MCP server's settings page. Dash0 opens the provider's authorization screen, and once you approve, the connection is established and the server's tools become available to Agent0 — no copying, pasting, or rotating tokens by hand.
Secure by design: OAuth credentials are stored separately from any custom headers you configure, and Dash0 manages the authorization token on your behalf. You can still add custom headers to an OAuth-connected server when a provider requires them, without affecting the OAuth connection.
Works across providers: OAuth support follows the standard MCP authorization spec, so it works with any MCP server that implements it — Dash0 automatically discovers each server's authorization endpoints and registers itself, with no per-server client setup required.
Available now for all Dash0 organizations. Set it up in Organization Settings → Integrations → Add → MCP, choose OAuth as the authentication type, and click Connect.
MCP catalogue in the Integrations Hub: Browse a curated catalogue of Model Context Protocol (MCP) servers directly in Dash0. Switch to the Agent0 MCPs tab in the Integrations Hub to discover servers grouped by category — observability, cloud, incident response, productivity, and more — so Agent0 can tap into the tools your team already relies on.
One-click connect with OAuth: Connect to MCP servers that support OAuth without leaving Dash0. From an MCP's detail page, Connect starts the OAuth flow in place — authorize once and Agent0 gets access to the server's tools, no manual token handling required.
Guided setup for every server: For servers that use bearer tokens or other credentials, Connect drops you into a settings form pre-filled with the server's name, URL, and authentication type, so you only need to supply your credentials. Servers with multiple regional endpoints let you pick the right one up front.
Unified search: The Hub search now spans both Dash0 platform integrations and MCP servers, so you can find what you need in one place.
We’ve replaced the fixed 10/30/60-second refresh picker with a single toggle, so Dash0 now keeps every chart and table fresh at the right cadence on its own.
Keeping a view live used to mean picking a refresh interval (10, 30, or 60 seconds) and hoping it was the right one. Too fast and you hammered the backend on charts that only change by the hour. Too slow and your live data lagged behind reality. And a refresh could yank rows out from under you mid-scroll or talk over a long-running query.
Adaptive auto-refresh replaces all of that with a single Auto toggle. Flip it on, and Dash0 picks the right pace for each view: charts refresh in step with their own resolution, so a high-resolution live chart updates frequently while an hour-wide one updates calmly. Explorer tables (logs, traces, metrics, resources, and more) quietly pause refreshing while you’re scrolled into the data and pick back up when you return to the top, so rows never jump around while you’re reading them.
It also knows when not to refresh. Switch to another browser tab and polling pauses until you come back. Lock your time range to a fixed window and auto-refresh steps aside entirely, since there’s no future data to fetch. The result: fresher dashboards and explorers with less noise, fewer wasted queries, and nothing shifting under your cursor.
Agent0 is now Generally Available (GA) inside Dash0. The old assistant has been replaced by an autonomous production AI built on a new execution runtime, with continuous environment scanning, full-loop investigation, and pull request generation against your codebase.
Continuous environment scanning. Agent0 scans your environment and surfaces what matters on the Dash0 landing view, including services that are failing with no alert coverage, infrastructure under memory or CPU pressure, and recent deployments correlated with health regressions.
Integrated experience. Ask Agent0 directly from the features you are seeing. Contextual suggestions appear as you navigate through Dash0 features and change selections.
Capabilities running in parallel. Continuous environment scanning. Natural-language Q&A across telemetry and codebase. Multi-signal correlation across logs, traces, metrics, and deployments. Asset generation (dashboards, alerts, runbooks, pull requests) validated against live telemetry before they ship. Frontend performance and user experience (Core Web Vitals, JavaScript errors, session behavior) correlated with backend telemetry.
Execution runtime, not a prompt chain. Agent0 now runs on a sandboxed environment that can clone repositories, execute commands, and iterate until each generated asset is validated against your actual telemetry. Same execution model as Claude Code and Codex.
Full-loop incident response. Agent0 investigates, identifies root cause down to the offending commit, and drafts a pull request on a new branch. Investigations include a visible hypothesis tree with evidence citations.
Validated dashboards and alerts. Generated dashboards use proper grid layouts with P50/P90/P95/P99 breakdowns when relevant. Every panel becomes an alert with one prompt. Every alert is validated against live telemetry before it ships.
Native integrations and tools. GitHub (code, PRs, CI status, fix generation), Linear (issue creation), Confluence and any MCP-compatible knowledge base, SQL, Bash, and any MCP server.
Updated chat view. Service-centric, surfaces what needs attention, with "Ask Agent0" contextual to whatever surface you're on.
New pricing. Task-based credits. No per-seat AI charges. No per-investigation fees.
Correlate spikes and dips in your time-series charts with what real users were doing. Web events from RUM can now be overlaid as annotations, alongside the existing log, Kubernetes, and service event sources.
Time-series widgets on dashboards already support annotations from logs, Kubernetes events, and service events. Today, web events join the party. Add a Web Events annotation to any time-series widget, filter it the way you would in the Web Events Explorer, and the matching events appear as markers on the chart's timeline. When markers cluster, they collapse into a single pill grouped per kind, so a burst of page loads stays visually distinct from, say, a deployment marker sitting right next to it. The chart legend now has its own "Web events" row too, counting them separately from logs. Each marker comes with a tooltip showing the event's attributes and a one-click link straight to the Web Events Explorer — with the same filter applied and the event already selected — so you can go from "what happened around 14:32?" to the exact session event without losing your place.
The OpenTelemetry K8s SIG has introduced new semantic conventions for replication controllers, horizontal pod autoscalers, persistent volumes and their claims, resource quotas and more. We added support for them in Dash0, alongside first-class support for the k8sobjectsrecevier and its (non semconv-compliant...) output.
We added new resource types and the associated resource equality, typing and naming rules: k8s.replicationcontroller, k8s.service, k8s.persistentvolume, k8s.persistentvolumeclaim, k8s.hpa, and k8s.resourcequota. We also added a new, generic k8s.object resource type for all Kubernetes resource types (including CRDs) that do not currently have semantic conventions, which is necessary to improve the experience with the k8sobjectsreceiver of the OpenTelemetry Collector.
The k8sobjectsreceiver sends one log record for each Kubernetes API state change it observes (object created, modified, or deleted), or a periodic snapshot in pull mode. Taking some liberties with the encoding (thankfully, OTLP/YAML is not a thing):
Since the only resource attribute is k8s.namespace.name, this log used to be associated with a k8s.namespace resource, alongside all others representing new versions of resources in the same namespace. Instead, we now extract from the body of the log additional k8s.* resource attributes:
yaml
what-you-find-in-dash0.yaml
123456789101112
ResourceLogs:
Resource:
k8s.namespace.name: dash0-validation # from regarding.namespace
k8s.pod.name: bad-image # per-Kind promotion
k8s.pod.uid: 91551565-71f9-4d88-9711-3bef7607a7a7
k8s.node.name: node-3# from reportingInstance / source.host
# (k8s.object.* generic keys removed: Pod has dedicated semconv)
event_name: k8s.object # this makes the log available for Annotations!
# The rest is the same
That is, you are going now to find your new versions of Pods and Deployments when you filters for those pods and deployments.
Additionally, since we replace the bogus event_name field with k8s.object, you can use these logs for dashboard annotations, and can overlay how your Kubernetes resources change to your telemetry!
We also added support to normalizing the format for Kubernetes events as reported by k8sobjectsreceiver to the format we already supported of k8seventsreceiver (because, for Kubernetes, events are resources the way a pod or a deployment are), which means you can standardsize of k8sobjectsreceiver rather than using additionally k8seventsreceiver.
Last but not least, we papered over a papercut in k8seventsreceiver, which set timestamps based on the timezone where the collector is deployed in. Now it will all be consistently UTC.
When troubleshooting slow or failing database queries, knowing which query ran is the first thing you need, but finding it buried in the Attributes tab is painful. Now it's front and center in the span sidebar, syntax-highlighted, with prepared statement parameters already filled in.
We added a dedicated query widget to the span sidebar. If your span is a database span — meaning it carries either the db.query.text or the legacy db.statement attribute — the query now appears front and center, with the same syntax highlighting already available in the Attributes tab. No more hunting.
Several OpenTelemetry instrumentations for Java, .NET, and Python collect prepared statement parameters and expose them as db.query.parameter.<id_or_key> span attributes. When we detect those attributes, we interpolate the values directly into the query so you can read it as it actually ran — no blanks to fill in manually.
The interpolated parameters are interactive: you can filter them in or out, inspect individual values, copy them to the clipboard, or pin them as a column in your span table.
Starting with Operator v0.141.0, the Dash0 Operator for Kubernetes supports capturing query parameters by setting instrumentWorkloads.captureSqlQueryParameters: true in your Dash0Monitoring resource. This opts you in to query parameter collection for all injected Java and .NET instrumentations (see the Operator documentation for details). As of this time, Python requires configuring the instrumentation in code, and for languages without automated instrumentation that emits query parameters (like Node.js) we did something else. Read on.
We updated the Agent Skills to help you set the collection of database query parameters for your Java, .NET and Python apps. It will also help you collect database query parameters for languages that do not have built-in support, using custom instrumentations.
