Recent changes and improvements to Dash0

Search spans like you search logs

The spans queryCopy command brings to spans the same filtering, output formats, and custom columns you already know from logs queryCopy:

1234
dash0 -X spans query \
    --from now-1h \
    --filter "service.name is checkout-service" \
    --filter "otel.span.status.code is ERROR"

The default table shows timestamp, duration, span name, status, service name, parent ID, trace ID, and span links. Swap in any OTLP attribute as a column to surface the dimensions that matter to your investigation:

12345
dash0 -X spans query \
    --column timestamp \
    --column duration \
    --column "span name" \
    --column http.request.method

JSON and CSV outputs are available for scripting and downstream processing.

Reconstruct full traces

Once you have a trace ID — from a span query, a log record, or an alerting rule — traces getCopy fetches every span in the trace and displays them as an indented tree:

1
dash0 -X traces get 0af7651916cd43dd8448eb211c80319c

Follow span links across trace boundaries

Modern architectures do not always fit into a single trace. A message queue consumer might link back to the producer's trace; a batch job might reference the request that triggered it.

The --follow-span-linksCopy flag tells the CLI to chase those connections automatically:

1
dash0 -X traces get 0af7651916cd43dd8448eb211c80319c --follow-span-links

The CLI walks span links recursively (up to 20 traces), displaying each linked trace under a clear header. You can set a custom lookback period for the linked traces, like --follow-span-links 2hCopy, to control how far back the search reaches.

Get started

1234
export DASH0_API_URL=... # Get the value at https://app.dash0.com/goto/settings/endpoints?endpoint_type=api_http
export DASH0_AUTH_TOKEN=... # Get the value at https://app.dash0.com/goto/settings/auth-tokens

dash0 -X spans query --from now-15m

Span and trace commands are experimental: enable them with -XCopy and tell us how they fit into your workflow.

Powerful filtering at your fingertips

The --filterCopy flag accepts the same expression language you use in the Dash0 UI so you can zero in on exactly the records that matter. Combine multiple filters (AND logic) to slice through millions of log lines in seconds:

12345
dash0 -X logs query \
    --from now-1h \
    --filter "service.name is api-gateway" \
    --filter "otel.log.severity.range is_one_of ERROR FATAL" \
    --limit 200

Supported operators range from exact matches (isCopy, is_notCopy) and substring checks (containsCopy, starts_withCopy) to regex (matchesCopy), numeric comparisons (gtCopy, gteCopy, ltCopy, lteCopy), and presence tests (is_setCopy, is_not_setCopy). If you can describe the condition in the Dash0 Logging Explorer, the CLI can express it.

Flexible output for humans and machines

By default, logs queryCopy prints a clean table with timestamp, severity, and body. Need the full OTLP payload for a script? Switch to --output jsonCopy. Feeding results into awkCopy or a spreadsheet? Use --output csvCopy.

Custom columns let you pull any attribute into view:

1234
dash0 -X logs query \
    --column time \
    --column service.name \
    --column body

Any OTLP attribute key, at resource, scope, or log record level, works as a column, so you see exactly the dimensions you care about.

Built for automation

Relative timestamps (now-15mCopy, now-1hCopy), machine-readable CSV output, and --skip-headerCopy make logs queryCopy a natural fit for shell scripts, CI checks, and AI-agent workflows. Pipe it into jqCopy, grepCopy, or your favorite data tool.

12345
# Count errors in the last 30 minutes
dash0 -X logs query \
    --from now-30m \
    --filter "otel.log.severity.range is ERROR" \
    -o csv --skip-header | wc -l

Get started

Install or update the Dash0 CLI, set your credentials, and start querying:

1234
export DASH0_API_URL=... # Get the value at https://app.dash0.com/goto/settings/endpoints?endpoint_type=api_http
export DASH0_AUTH_TOKEN=... # Get the value at https://app.dash0.com/goto/settings/auth-tokens

dash0 -X logs query --from now-1h

Logs query is an experimental command: enable it with the -XCopy flag and let us know what you think.

We have extended the following tools with comprehensive management capabilities for members and teams:

• The official Dash0 API
• The Dash0 Go API Client
• The dash0 CLI (Command Line Interface)

Teams Management

The core team API endpoints, starting with /teamsCopy, cover operations like:

• Retrieving a list of all teams in your organization.
• Creating new teams with specific access configurations.
• Adding and removing members from teams.
• Fetching details for a single team.
• Updating existing team properties, such as the name.
• Deleting teams.

CLI Snippets

1234567891011
# List all teams
dash0 teams -X list

# Create a new team
dash0 teams -X create --name "Frontend Developers"

# Add members to a team
dash0 teams -X add-members <teamId> <memberIdOrEmail> <memberIdOrEmail> <memberIdOrEmail>

# Delete a team
dash0 teams -X delete <teamId>

The teamsCopy command is currently experimental (like all recently introduced commands), and therefore requires the –X/-–experimentalCopy flag.

Members Management

The API endpoints under /membersCopy let you manage individuals in your organization:

• Listing all members in the organization.
• Inviting new users to the organization.
• Managing member roles and permissions.

CLI Snippets

12345678
# List all members
dash0 members -X list

# Invite a new user
dash0 members -X invite "user@example.com"

# Invite a new user
dash0 members -X remove "user@example.com"

The membersCopy command is currently experimental (like all recently introduced commands), and therefore requires the –X/-–experimentalCopy flag.

What's New

Pin filters: Pin any filter to carry it across pages. Navigate from Trace Explorer to Log Explorer, Services, or Resources and your pinned filters are already there. No need to re-enter the same context on every page.

Conflict detection: The filter bar now detects when two active filters check the same key with different values and shows a warning. This commonly happens when opening a link from a teammate that has filters already applied.

Conflict resolution: When a conflict is detected, Dash0 offers a merge — the conflicting values become a single filter that matches any of them. Accept with one click.

Copy individual filters: Copy a single filter without copying your entire filter list. Expand a filter and click the copy icon.

Updated filter bar: Filters are more compact by default and expand on interaction to show available actions (pin, copy). They auto-collapse when not in use.

Available in: Trace Explorer, Log Explorer, Services, Resources, Websites, and Failed Checks.

A latency spike tells you something is wrong. Seeing a pod restart or a container reschedule seconds earlier tells you why. Dashboard annotations put those events directly on your charts.

When editing a panel, click Add annotation, pick an event type, scope it to a service, and add filters. You can add multiple annotations per panel to layer different event scopes on the same chart. Click any marker on the timeline to see full event details.

Annotations work with events already flowing into Dash0. If you’re not collecting events yet, the Dash0 Kubernetes operator (v0.92.1+) gathers Kubernetes events automatically from monitored namespaces. For application-level events, any structured log record with an otel.event.name attribute is recognized as a log event and can be used as an annotation source.

Starting with version 0.102.0 of the Dash0 Kubernetes Operator, you can configure any number and combination of backends that best fits your requirements and the operator will ensure the collectors send the data to all of them.

Together with the previously released per-namespace export and API sync configuration, this allows a very flexible routing to different backends.

For example, to send the data from one namespace to two different Dash0 datasets and in addition to a gRPC endpoint, you could use the following exportsCopy in your Dash0MonitoringCopy config:

12345678910111213141516171819202122
apiVersion: operator.dash0.com/v1beta1
kind: Dash0Monitoring
metadata:
  name: dash0-monitoring-resource
  namespace: some-namespace
spec:
  exports:
    - dash0:
        endpoint: ingress...
        dataset: custom-dataset-one
        authorization:
          ...
        apiEndpoint: https://api..
    - dash0:
        endpoint: ingress...
        dataset: custom-dataset-two
        authorization:
          ...
        apiEndpoint: https://api..
    - grpc:
        endpoint: ...
  ...

You can find more details in the operator's documentation.

Log events in OpenTelemetry are a subset of log records with a special field, EventName, that specifies the type of event it represents. Log events of the same type are supposed to use the same schema for their body.

(Foreshadowing: soon you are going to care a lot about log events in Dash0. Dun dun DUN!)

EventName being a field in OTLP has been an issue: support for OTLP fields is very sparse beyond the Logs API in the SDKs (with notable SDKs not having support to this day) and the OpenTelemetry Collector. Most other logging agents that can send logs over OTLP do not support fields for log records beyond timestamp, body and attributes. And since attributes are generally well supported in the ecosystem, OpenTelemetry Semantic Conventions v1.39.0 introduced otel.event.name as an attribute-level fallback for the EventName field.

In compliance with the semantic conventions, Dash0 now supports otel.event.name as fallback for the EventName field. Log records ingested via OTLP that do not have the EventName field set, are nevertheless treated as log events also when the otel.event.name attribute is present. The same applies to other structured log formats: their logs are similarly handled as log events when the top-level otel.event.name field is set.

Observability is a marathon, not a sprint. While our default dark interface is a favorite for many, we know that lighting conditions and personal preferences vary throughout the day. To give you more flexibility in how you monitor your systems, we’re introducing a Light Mode option for the entire Dash0 UI.

Designed for clarity We’ve carefully adapted our interface to ensure that the transition to a lighter palette feels natural. Every component—from the Service Map to complex trace views—has been refined to maintain the visual hierarchy you're used to. Whether you’re working in a sunlit room or simply prefer a paper-like aesthetic, the new theme provides a clean, focused environment for your data.

What’s new:

• Visual Flexibility — Easily switch between Light and Dark modes to match your surroundings or personal workflow.
• Consistent Semantics — We’ve tuned our color palette so that critical status indicators and OTel metrics remain clear and recognizable against the lighter background.
• Automatic Switching — Set Dash0 to "System" mode to have the UI automatically sync with your OS theme as the day turns into night.

How to switch The fastest way to change your theme is via the Command Menu:

1. Press CMD+KCopy (or CTRL+KCopy) to open the menu.
2. Type "Theme" and select your preferred mode.

Alternatively, you can click on your profile avatar in the sidebar to find the theme selector under your account settings.

The monthly budget limits the total amount due on your invoice across all signal types — spans, logs, metric data points, web events, and synthetic API checks.

Key features

• Advance warnings - Dash0 notifies you at 75% and 90% of your budget via in-app banners and emails to organization admins.
• 4-day grace period - When your budget is reached, telemetry continues to be ingested for 4 days at no additional charge, giving you time to react.
• No data loss - After the grace period, ingestion is paused automatically. Historical data and configuration remain fully accessible.
• Full flexibility - Modify or remove your budget at any time from Settings > Billing & Plans.
  

Prerequisites

You must have the Admin role in your organization. Members without the Admin role cannot view or modify the monthly budget.

To set a monthly budget, navigate to Settings > Billing & Plans and click Set monthly budget in the Next invoice card.

You can find more details in the monthly budget documentation.

The Dash0 CLI enables you to manage your observability assets programmatically, making it easy to version control dashboards, implement GitOps workflows, and automate your observability infrastructure from shell, scripts and agentic AI.

Key features

- GitOps-Ready Asset Management — Create, update, and delete dashboards, check rules, synthetic checks, and views using declarative YAML files. Use the apply command to sync your assets from version control, with support for dry-run validation before making changes.
- Multi-Environment Profiles — Configure multiple profiles for different environments (dev, staging, production) and switch between them seamlessly. Environment variables provide additional flexibility for CI/CD integration.
- Flexible Output Formats — Export assets in table, wide, JSON, or YAML formats for easy scripting, reporting, and backup workflows.

Quick start

# Install via Homebrew
brew tap dash0hq/dash0-cli https://github.com/dash0hq/dash0-cli && brew install dash0hq/dash0-cli/dash0Copy

# Configure your profile
dash0 config profiles create prod \
--api-url https://api.eu-west-1.aws.dash0.com \
--auth-token auth_xxxCopy

# Apply your assets
dash0 apply -f dashboards/Copy

Try it out

The Dash0 CLI is open source and available on https://github.com/dash0hq/dash0-cli. We welcome contributions and feedback from the community.

Let us know which additional features you would like to see!