Recent changes and improvements to Dash0

OAuth login

OAuth support was the most requested (by a wide margin!) feature request for the dash0Copy CLI.

dash0 loginCopy 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_*Copy tokens still work, although when you change a profile to use OAuth, the previous access token gets overwritten.

Create an OAuth profile and authenticate:

123
dash0 config profiles create prod --oauth \
  --api-url https://api.eu-west-1.aws.dash0.com
dash0 login --profile prod

dash0 config showCopy annotates the auth state, so you always see whether a token is static, OAuth-active (with remaining lifetime), or OAuth-empty:

123
Profile:    prod
API URL:    https://api.eu-west-1.aws.dash0.com
Auth Token: ...1234567    (OAuth, expires in 14m20)

The dash0Copy 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:

1
dash0 logout --profile prod

Safe by default for AI agents: When Claude Code, Cursor, or another coding agent invokes the CLI, dash0 loginCopy refuses to open a browser and dash0 logoutCopy requires explicit --forceCopy — so an agent cannot silently rotate or revoke a profile's OAuth session. Errors point agents at the recovery paths instead:

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
      `dash0 config profiles update prod --oauth=false --auth-token auth_<...> --force`.

Local OTLP proxy

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 proxyCopy.

dash0 -X otlp proxyCopy runs a foreground forwarder on 127.0.0.1:4318Copy (OTLP/HTTP) and 127.0.0.1:4317Copy (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.

Just run it:

1234
dash0 otlp proxy listening — http://127.0.0.1:4318 (OTLP/HTTP), 127.0.0.1:4317 (OTLP/gRPC) — profile: dev (dataset: default)
   logs:    42/s ▁▂▄▆▇ 1234 total
  spans:    18/s ▁▂▃▄▅  540 total
metrics:     0/s ▁▁▁▁▁    0 total

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:

123
dash0 -X otlp proxy \
  --resource-attribute developer=alice \
  --resource-attribute deployment.environment.name=local

Or watch every forwarded record in the same style as the Collector's debug exporter while you iterate on instrumentation:

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.

Precision mode for queries

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.idCopy, a test.idCopy from CI, a request ID), pass --precision disabledCopy:

12
dash0 logs query --precision disabled --filter "test.id is 7a3f…"
dash0 spans query --precision disabled --filter "trace.id is 0af7651916cd43dd8448eb211c80319c"

traces getCopy always runs in Precision mode, so a retrieved trace is never missing spans regardless of the query window.

Streamlined Homebrew install

The CLI's Homebrew distribution has moved to a dedicated tap (dash0hq/homebrew-dash0-cliCopy) 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 tapCopy, no brew trustCopy (introduced with Homebrew 6.0):

1
brew install --cask dash0hq/dash0-cli/dash0

Existing users see a deprecation warning on brew upgrade dash0Copy pointing at the new path. The migration is a one-time three-step procedure:

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 dash0Copy CLI.

See the full migration guide for context on the Homebrew 6.0 tap-trust changes that motivated the move.

Available now!

All this is available now in Dash0 CLI 1.14.0. Upgrade via Homebrew with brew upgrade --cask dash0Copy (after migrating from the legacy formula), pull the latest container with docker pull ghcr.io/dash0hq/cli:latestCopy, or download a binary directly from the GitHub release.

What's New

• 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.

Availability

Available now for all Dash0 organizations. Set it up in Organization Settings → Integrations → Add → MCPCopy, choose OAuth as the authentication type, and click Connect.

What's New

• 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.

Availability

Available now for all Dash0 organizations. Browse it in the Integrations Hub → Agent0 MCPsCopy, or open directly.

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.

What's new

• 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.

Try out the new agent and read more about it in our documentation.

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.

New resource types

We added new resource types and the associated resource equality, typing and naming rules: k8s.replicationcontrollerCopy, k8s.serviceCopy, k8s.persistentvolumeCopy, k8s.persistentvolumeclaimCopy, k8s.hpaCopy, and k8s.resourcequotaCopy. We also added a new, generic k8s.objectCopy 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 k8sobjectsreceiverCopy of the OpenTelemetry Collector.

Improving the experience with the k8sobjectsreceiver

The k8sobjectsreceiverCopy 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):

sample-k8sobjectsreceiver.yaml
123456789101112131415161718192021222324252627282930313233343536373839
ResourceLogs:
  Resource:
    k8s.namespace.name: dash0-validation
  ScopeLogs:
    scope.name: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/k8sobjectsreceiver
    LogRecords:
    - timestamp: 1970-01-01T00:00:00Z           # receiver leaves it zero
      severity_number: Unspecified              # receiver has no Event knowledge
      severity_text: ""
      event_name: ""
      attributes:
        k8s.resource.name: events
        event.domain: k8s
        event.name: bad-image.18b32f4314df584e  # verbatim Event.metadata.name
      body:                                     # watch mode
        type: MODIFIED
        object:
          apiVersion: events.k8s.io/v1
          kind: Event
          metadata:
            name: bad-image.18b32f4314df584e
            namespace: dash0-validation
            uid: 75309f4a-a6e9-4250-afa8-447ce7afdbe8
            resourceVersion: "508"
            creationTimestamp: "2026-05-26T17:57:22Z"
          regarding:
            apiVersion: v1
            kind: Pod
            name: bad-image
            namespace: dash0-validation
            uid: 91551565-71f9-4d88-9711-3bef7607a7a7
            fieldPath: spec.containers{bad}
            resourceVersion: "508"
          reason: BackOff
          note: 'Back-off pulling image "this-image-does-not-exist.example.com/never:latest"'
          eventTime: "2026-05-26T17:57:22Z"
          reportingController: kubelet
          reportingInstance: node-3
          type: Normal

Since the only resource attribute is k8s.namespace.nameCopy, this log used to be associated with a k8s.namespaceCopy 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.*Copy resource attributes:

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)
  ScopeLogs:
    scope.name: github.com/dash0hq/dash0-opentelemetry-collector/processor/dash0k8sobjectprocessor
    LogRecords:
      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_nameCopy field with k8s.objectCopy, 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 k8sobjectsreceiverCopy to the format we already supported of k8seventsreceiverCopy (because, for Kubernetes, events are resources the way a pod or a deployment are), which means you can standardsize of k8sobjectsreceiverCopy rather than using additionally k8seventsreceiverCopy.

Last but not least, we papered over a papercut in k8seventsreceiverCopy, which set timestamps based on the timezone where the collector is deployed in. Now it will all be consistently UTC.

Further reading

• Updated resource equality, naming and typing rules for Kubernetes
• How Dash0 Processes Kubernetes Object Logs

Making database queries easy to find

We added a dedicated query widget to the span sidebar. If your span is a database span — meaning it carries either the db.query.textCopy or the legacy db.statementCopy attribute — the query now appears front and center, with the same syntax highlighting already available in the Attributes tab. No more hunting.

Query parameters for prepared statements

Several OpenTelemetry instrumentations for Java, .NET, and Python collect prepared statement parameters and expose them as db.query.parameter.<id_or_key>Copy 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.

Enabling query parameters with the Dash0 Operator for Kubernetes

Starting with Operator v0.141.0, the Dash0 Operator for Kubernetes supports capturing query parameters by setting instrumentWorkloads.captureSqlQueryParameters: trueCopy in your Dash0MonitoringCopy 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.

Not using the Dash0 Operator, or libraries that collect database query parameters?

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.

What's New

• Inline drilldown from any chart — Time-series, pie, gauge, stat, and tree-map charts now drill straight into the records behind them.
• Searchable picker for multi-time-series charts — Charts with many series open a dialog with live counts of matching records per series and full keyboard navigation.
• Per-(series × signal) drilldowns — Multi-series and multi-signal charts produce independent drilldowns, each scoped to its row's labels and its signal's filters.
• Explore and Triage modes — Read records with Explore, or surface what differentiates them with Triage. Available for spans, logs, and web events.
• Filter and time-range carry-over — Filters from PromQL and series labels and your selected time range follow you into the destination explorer with no manual setup.
  

Why This Matters

Explore data behind a chart used to mean hopping between a dashboard, the spans explorer, the logs explorer, and a metric drilldown — copying filter values and time ranges across each step. Drilldown collapses that sequence into a single click. You can spot a misbehaving series, drill straight into its underlying data, and keep visual context throughout, without any manual filter setup.

Try It

Open any dashboard, select a time range on one of your charts, and pick Explore or Triage in the action bar. For pie, gauge, stat, and tree map panels, click a segment instead.

The Drill Down from Charts documentation covers every entry point per chart type, keyboard shortcuts, the Explore vs. Triage decision, and the filter translation rules.

Kudos Are Due

The logic to decide which telemetry is used in a PromQL query has been devised together with Julius Volz, one of the founders of Prometheus and the mind behind PromLabs. If you want to learn Prometheus, we cannot recommend the self-paced courses enough, they are effectively a rite of passage at Dash0.

Setting up alerting for a new technology has always been the slow part of getting full coverage. You know which metrics matter, but you still have to write the PromQL, decide on thresholds, and pick severities. Now we do that for you.

Every integration in the Hub has a Check Rules section listing the alerts most worth running for that technology. Browse them on the public Integrations Hub at dash0.com/hub before you sign up, or open them from the in-app integration page and install with one click; already configured with sensible thresholds and severities.
Each rule card is transparent about what it does and what it needs. You can see which of its metrics are already flowing into your organization and get a clear pointer if a dependency integration isn't set up yet; added rules are also disabled by default so you don’t need to worry about them spamming you immediately before you make modifications.
Once added, these rules behave like any check rule you authored yourself; you can edit, route to notification channels, adjust thresholds. The Hub is a curated starting point, not a black box.