Dash0 CLI
$
npx @buildinternet/releases get dash0-cliMon
Wed
Fri
NovDecJanFebMarAprMayJunJulAugSepOctNov
LessMore
Releases6Avg2/moVersionsv1.16.5 to v1.21.0
npx @buildinternet/releases get dash0-cliAll notable changes to this project will be documented in this file.
The format is based on Keep a Changelog.
signal-to-metrics-rules: Manage signal-to-metrics rules with signal-to-metrics-rules (alias s2m) and apply. (#354)
apply accepts the Dash0SignalToMetrics kind and upserts by dash0.com/origin, and apply --since deletes a rule removed from git.
s2m test -f <file> validates a rule and counts the logs or spans it matches over a time window, without creating it.
evals: dash0 -X evals list|get|create|update|delete and apply manage the generative AI evaluations (evals) of a dataset. (#360)
apply accepts kind: Dash0GenerativeAiEvaluation documents and upserts them by dash0.com/origin, with dash0.com/id as the fallback.
The CLI never sends dash0.com/version, so a write overwrites the stored eval unconditionally.
A change to metadata.name or to the judge output kind fails with an error that names the field and the fix.
apply --since deletes an eval whose document was removed from git.
diff: Add the experimental dash0 diff command, which previews what apply would do (creates, updates, and, with --since, deletions) without ever mutating anything. (#232)
diff fetches each document's current state from Dash0 first, so it can accurately distinguish a create from
an update, unlike apply --dry-run, which is local-only and cannot tell the two apart. It uses a three-way
exit code (0 clean, 1 differences pending, 2 error), modeled on kubectl diff.
The comparison (also used by every <kind> update diff) is semantic, not textual: key order, duration-string
formatting, int-vs-float representation, and API-populated defaults never produce a spurious "changed" result.
apply --since --dry-run no longer lists the deletion of a check rule that -f still declares, because the real
run skips that deletion.
apply --since --dry-run lists a removed PrometheusRule with two or more alerts as one check rule deletion per
alert, at the id the run deletes, instead of one PrometheusRule row.
apply and teams create -f update a team at its dash0.com/id when its dash0.com/origin is not found, so a
re-applied export of an SSO/SCIM-provisioned team no longer creates a second team.
logs, spans, traces, failed-checks: The Dash0 explorer deep link of a query is now available in every output format, not just table. (#348)
logs query, spans query, failed-checks query, and traces get carry the link in json output as a top-level dash0ExplorerUrl field, next to the payload, so it is available in agent mode, where json is the default.
In table and csv output the link now goes to stderr instead of stdout, so redirecting or piping the results no longer picks up a stray line.
The field is omitted when no link can be built, for example when the api-url host is localhost.
Consumers that parse the OTLP/JSON of logs query, spans query, or traces get with a strict OpenTelemetry protobuf-JSON parser need to discard unknown fields, or strip the field with jq 'del(.dash0ExplorerUrl)'.client: Report malformed asset API responses with the asset type, endpoint, and decoding details, and warn when a write may already have been applied. (#220)
apply: apply --since no longer deletes a dashboard whose file was re-authored between the PersesDashboard and Dashboard kinds under the same identifier. (#270)
--since now treats both kinds as one identity, matching how apply upserts them.
github-actions: The setup action resolves the latest published CLI release instead of the newest git tag, so it no longer fails with a 404 while a release is still building. (#352)
The release tag is pushed before GoReleaser uploads the assets, leaving a window
(about 7 minutes for v1.20.0) in which the newest tag names a version whose download
URL 404s. Resolving /releases/latest only ever yields a release whose assets exist.
deeplinks: The CLI no longer prints a deep link to a nonexistent host when the API URL is an IP address. (#359)
With an API URL such as http://127.0.0.1:8080, the URL column, the URL: line, and the explorer link of query commands showed a host such as app.0.1. They are now omitted.
An API URL with a trailing dot, such as https://api.dash0.com., now links to app.dash0.com instead of app.com.
views: views create, update, get, and apply keep the spec.frameFilters, spec.profileType, spec.stackFilters, and spec.sumBy fields of profile views. (#359)
Before, the CLI dropped these fields without a warning, so a profile view did not round-trip through get -o yaml and apply.
auth-tokens: dash0 -X auth-tokens list|get|create|update|delete manages the auth tokens of your organization. (#329)
create prints the new token's secret once on an interactive terminal, or writes it to a new file with --secret-file.
In CI, in a pipe, or in agent mode, create fails before it creates anything unless --secret-file is set.
No other command or output format shows the secret.
Granting the * action needs --allow-all-actions.
apply does not support auth tokens yet.
aws-metric-scrape-configs: dash0 -X aws-metric-scrape-configs get|update|delete manages which CloudWatch metrics Dash0 scrapes for an AWS integration, and apply accepts Dash0AwsMetricScrapeConfig documents. (#340)
Each AWS integration has one scrape config, addressed by the integration id.
update and apply replace the whole config, and delete clears it while keeping the integration.
A config exported with get -o yaml applies back without a diff.
A document without spec.namespaces, or with an unknown field under spec, fails before any API call.
agent0: dash0 -X agent0 skills list|get|create|update|delete and apply manage the Agent0 custom skills of your organization. (#347)
apply accepts kind: Dash0Skill documents and upserts them by dash0.com/origin; without an origin, dash0.com/id updates an existing skill only.
spec.permissions, defaultEnabled included, round-trips through agent0 skills get -o yaml and apply.
spec.source and the per-user dash0.com/enabled annotation are never sent.
apply --since deletes a skill whose document was removed from git.
members: Display organization roles in members list output. (#69)
The members list table displays full role values and leaves missing roles blank.homebrew: The Homebrew cask uses postflight_steps instead of the deprecated postflight, so Homebrew no longer warns about it. (#330)
github-actions: The setup, send-log-event and sync-assets actions no longer trigger the Node.js 20 deprecation warning. (#336)
actions/cache/restore and actions/cache/save move from v4.3.0 (Node.js 20) to v6.1.0 (Node.js 24).
agent-mode: --agent-mode now takes precedence over DASH0_AGENT_MODE, so --agent-mode=false disables agent mode and DASH0_AGENT_MODE=0 no longer overrides --agent-mode. (#296)
All settings now follow one precedence order: CLI flags, then environment variables, then the profile, then the default.
The documentation for connection settings (api-url, otlp-url, auth-token, dataset) incorrectly listed environment variables above CLI flags and is now corrected; their behavior is unchanged.datasets: Add the experimental datasets commands and Dash0Dataset support in apply (#309)
datasets list, get, create, update, and delete require --experimental.
Deleting a dataset keeps its dashboards, check rules, synthetic checks, and views for 30 days. Telemetry is removed as its retention expires.
apply --since deletes a dataset removed from git as a 30-day soft delete, and needs --force in agent mode.
The sync-assets action always passes --experimental, so dataset documents also work without since.apply: Fail validation when two check rules in one run resolve to the same ID, instead of applying both and keeping only the last one. (#317)
The check covers CheckRule documents and the per-alert IDs of PrometheusRule CRDs, in one file or across files.
The error names the ID and every document that uses it.
config: Add the global --config-dir flag to override the configuration directory (#298)
The configuration directory is resolved in this order: --config-dir, DASH0_CONFIG_DIR, ~/.dash0.
config: Add the global --auth-token-file flag to read the auth token from a file. (#299)
The file must contain only the auth token; surrounding whitespace is removed.
This supports Kubernetes secrets, Docker secrets, and systemd credentials that are mounted as files.
Also, dash0 api and dash0 metrics instant now honor --auth-token when the active profile uses a static token.
check-rules: Show deleted check rules as deleted, instead of like active ones. (#318)
check-rules get shows a Deleted: line in table output, and the dash0.com/deleted-at annotation in YAML and JSON output.
apply, check-rules create, and check-rules update print restored when they bring back a deleted check rule, and fail if the API keeps it deleted.
apply and check-rules update also show a diff of any other fields that changed.
assets: Show deleted dashboards, views, synthetic checks, SLOs, recording rules, and time series aggregations as deleted, instead of like active ones. (#319)
get shows a Deleted: line in table output, and the dash0.com/deleted-at annotation in YAML and JSON output.
apply, create, and update print restored when they bring back a deleted asset, and fail if the API keeps it deleted.
apply and update also show a diff of any other fields that changed.
update --dry-run on a deleted asset of any kind, check rules included, prints would be restored, and the asset stays deleted.
dashboards: Show <name> placeholders in table and wide output, empty names in CSV, and stderr warnings when individual dashboard name lookups fail. (#286)
Other rows remain visible and name lookup failures do not change the exit status. JSON and YAML exports continue to return fetch errors.
apply: Keep unquoted y, n, yes, no, on, and off keys as strings in YAML input, so a dashboard grid item's y key is no longer sent as "true". (#306)
YAML generators such as PyYAML write these words without quotes.
Values are not changed by this fix.
This affects apply and every create and update command.
github-actions: Add the sync-assets GitHub Action for syncing a directory of Dash0 asset YAML files, deleting assets removed since the last push (#277)
Wraps dash0 apply --since <ref>, deriving <ref> from the triggering event so a workflow does
not have to hand-write github.event.before's corner cases itself.
See .github/actions/sync-assets/README.md for the full reference.
time-series-aggregations: Add the time-series-aggregations command group (alias tsa) and the Dash0TimeSeriesAggregation kind to apply (#281)
The five standard CRUD subcommands (list, get, create, update, delete) are available as
dash0 time-series-aggregations <subcommand> or dash0 tsa <subcommand>, and apply accepts
kind: Dash0TimeSeriesAggregation documents.
Three behaviors differ from the other asset kinds:
metadata.labels["dash0.com/origin"] is mandatory and is the only upsert key. The API rejects an
aggregation without an origin, so there is no server-assigned-id fallback and no plain create: both
create -f and apply -f PUT to the origin, which is create-or-replace. A document without the
label fails before any API call, and during apply's validation phase before any document in the
run is applied.A dash0.com/id in a document body is ignored by the API, so a definition exported with
tsa get -o yaml reapplies as a clean no-op.
slos: Add dash0 slos commands to manage service level objectives (SLOs) as code (#206)
SLO documents use the OpenSLO v1 format (apiVersion: openslo.com/v1, kind: SLO) and are dataset-scoped via --dataset.
The commands support create, list, get, update, and delete, and SLOs can also be managed through dash0 apply.
SLO IDs are assigned by the server, so metadata.labels["dash0.com/origin"] is the upsert key: pin it in version control to make apply idempotent.
slos get and slos delete accept an origin or an ID, slos list -o wide and -o csv expose an ORIGIN column, and slos get prints Origin:.
dashboards, check-rules, views, synthetic-checks, recording-rules, notification-channels, spam-filters, teams, time-series-aggregations: Make update speak with one voice about which asset it addresses (#281)
Every update command resolves the same thing — whether to address the asset named by the
positional argument, the document's dash0.com/origin, or its id — and each one used to answer
it with its own wording. The same mistake produced a different message depending on which asset
type you typed.
The wording is now uniform, and more precise than what it replaces:
no <asset> id given: pass one as an argument, or set the id in the file, and for the kinds that upsert by origin (spam filters, teams, time series aggregations)
no <asset> origin or id given: pass one as an argument, or set metadata.labels["dash0.com/origin"] in the file.Only the message text changed; which asset each invocation resolves to is unchanged.
login: Send client_id on OAuth token revocation requests (#249)
dash0 logout, dash0 login (on re-login), and dash0 config profiles update --oauth=false now
include the profile's client_id when revoking a refresh token, matching the authorization server's
requirement. Without it, revocation silently failed and the old refresh token stayed valid.apply: apply --dry-run changed its output shape, including without --since (#253)
--since renders its deletions in the same listing as creates and updates, so that
listing had to name each row's operation and order the two kinds of row together. Plain
--dry-run shares the renderer and therefore changed too, in three ways:
* and its operation instead of a per-file ordinal:
1. Dashboard "Production Overview" (a1b2c3d4-...) becomes
* Apply Dashboard "Production Overview" (a1b2c3d4-...).--dry-run now emits the documented JSON array of
{path, changes: [{op, kind, name, originOrId}]} instead of the human-readable text,
matching every other command's agent-mode contract.Separately, Dash0Team now renders as Team wherever an asset kind is displayed, so
apply reports Team "Backend Team" created instead of Dash0Team "Backend Team" created. Every other kind already had a human-readable display name; teams fell
through to the raw kind identifier, which also contradicted the --- Team (before)
header their own update diff printed.
Scripts that parsed --dry-run's text output, or grepped for Dash0Team, need
updating. Agent-mode callers should read the JSON rather than parsing text.
apply: Add apply --since <ref> and --force for git-history-based deletion sync (#253)
Deletes assets whose definition existed at <ref> but is no longer present in -f's
current contents, detected by identifier (id or origin), never by file path. Requires
--experimental/-X. --dry-run --since previews the deletion plan, merged with the
existing create/update preview into one per-file listing, and now also resolves deleted
assets' names from git history instead of only showing their id. Agent mode emits
--dry-run's preview as JSON.
Also, while stabilizing this feature ahead of release:
--since now correctly detects an all-deletions run, whether -f's target survives
empty or was removed entirely, instead of failing outright.record: entry is removed, even
though the CRD's own identifier survives via a remaining alert: entry.--force, which keeps its own separate job of skipping confirmation
prompts.--accept-non-ancestor-ref flag accepts a non-ancestor --since ref (e.g. after
a force-push) without also skipping every per-asset deletion confirmation, which
--force alone used to do together.--since-independent bug in apply/check-rules create: a
PrometheusRule CRD with 2+ alerting rules and a dash0.com/id label silently
collapsed to one check rule (the last alert applied overwrote the rest under the
shared id). Each alert now upserts its own derived id. Re-applying an existing
multi-alert CRD leaves an orphaned duplicate at the literal dash0.com/id; delete it
by hand once the new per-alert check rules look correct.apply: Retry a 409 dataset version conflict instead of failing immediately when creating or updating dashboards, check rules, views, recording rules, synthetic checks, or spam filters (#261)
Two dash0 processes (e.g. a CI matrix, or a script running concurrent apply/create/update
commands) writing to the same dataset at once could previously race the dataset's optimistic-concurrency
version check: the losing write got a 409 that nothing retried, and surfaced as a fatal error. The losing
write is now retried with backoff, up to the existing --max-retries/DASH0_MAX_RETRIES budget.check-rules: Merge a PrometheusRule CRD's top-level metadata.annotations into each rule's own annotations, matching the Dash0 Kubernetes operator and Terraform provider (#245)
Previously, a common setting defined once at the top level of a multi-rule PrometheusRule document -
most importantly dash0.com/notification-channel-ids - was silently dropped for any rule that did not
repeat it on its own annotations. A rule's own annotations still take precedence when the same key is
set in both places. This affects check-rules create and check-rules update on PrometheusRule CRD
input, and apply.
auth: Refresh OAuth access tokens for the whole duration of a command, not just at startup (#258)
An OAuth access token lasts 15 minutes, and the CLI resolved it once at startup then reused
it for the rest of the command. Anything that ran longer failed partway through with
authentication failed; check your auth token (status: 401), leaving partial output. Large
exports hit this most often, such as dash0 logs query --from now-7d -o json, along with
bulk dash0 apply -f runs and list over many assets.
The token is now resolved before every request and refreshed as it nears expiry, so a long
command finishes on one dash0 login. A request rejected with 401 is retried once with a
fresh token, which also covers a token revoked elsewhere and clock skew against the
authorization server.
--profile <name> and DASH0_PROFILE never refreshed at all, serving whatever token sat
on disk. They now refresh like the active profile.
Static auth_* tokens do not expire and are still sent unchanged.
teams: teams update now accepts -f <file> with a TeamDefinitionV1Alpha1 document, enabling the export → edit → reapply workflow every other asset kind already supports. (#237)
The imperative --name, --color-from, and --color-to flags keep working for backward compatibility but are now deprecated in favor of -f.
Unlike teams create -f, teams update -f does not create a team on 404 — the target must already exist.config: Setting DASH0_AUTH_TOKEN together with DASH0_API_URL or DASH0_OTLP_URL no longer discards the rest of the active profile, so the profile's dataset reaches the API again. (#240)
That combination used to bypass the active profile wholesale, so requests went out with no
dataset query parameter and the API fell back to default — while dash0 config show kept
reporting the profile's dataset, leaving nothing in the CLI to tell you the two disagreed.
Every setting is now resolved on its own, as docs/commands.md has always documented: an
environment variable overrides only the setting it names, and otlp-url and dataset keep
coming from the profile.
--dataset and DASH0_DATASET are unaffected, and env vars alone still work with no profile
configured at all.
views, synthetic-checks: spec.permissions on views and synthetic checks is now sorted lexicographically (by role, then team, then user) before being displayed or diffed. (#231)
The Dash0 API does not guarantee a stable order for this field, which previously showed up as
spurious changes in views/synthetic-checks update --dry-run and apply diffs, and as
reordered output across repeated get/list -o yaml calls.
metrics: metrics instant's verbose table output now prints Prometheus labels in a stable, sorted order instead of Go's randomized map iteration order. (#231)
Part of an audit into non-deterministic key/array ordering in CLI output (see docs/code-style.md's
"Deterministic output ordering" section for the pattern and the guardrail added against recurrence).
notification-channels: Warn when a Dash0NotificationChannel definition carries a non-empty spec.routing.assets, and omit the API-managed field from exports (#15826)
spec.routing.assets lists the check rules and synthetic checks bound to the channel; the Dash0
API populates it as a back-reference and silently ignores any value supplied on write (existing
bindings are unaffected). apply, notification-channels create, and notification-channels update now warn when a definition carries non-empty assets, pointing at the supported binding
mechanisms (the check rule's dash0.com/notification-channel-ids annotation, the synthetic
check's spec.notifications.channels). notification-channels get and list omit the field
from -o yaml/-o json output, so exported definitions re-apply without warnings.
teams: teams create -f and apply are now idempotent for team YAMLs downloaded from the Dash0 platform UI (#227)
ImportTeam now consults dash0.com/id in metadata.labels as a fallback
upsert key when dash0.com/origin is not set — the API accepts either as
the {originOrId} path segment. UI-downloaded YAMLs carry only id, so
before this fix every create -f and every apply POSTed a new team.
For the cross-environment case (a YAML downloaded from one org, applied to
another), a preflight GET /api/teams/{id} gates the routing: on hit the
CLI PUTs (idempotent update), on miss it falls back to POST (fresh create,
the id in the file becomes advisory). Previously the miss path surfaced as
a "Forbidden: The given team does not belong to your organization" 404.
Origin still wins when both labels are present.
delete: delete --force now treats an already-deleted asset as idempotent success (#217)
Every delete subcommand (dashboards, check-rules, synthetic-checks, views,
recording-rules, notification-channels, spam-filters, teams) and every
remove-shaped variant (members remove, teams remove-members) now
exits 0 and prints a short "already deleted" line to stderr when the target
is already gone and --force was set. The remove variants apply the
check per member so one concurrently-removed member does not fail the
whole --force call. Without --force, a missing target still surfaces
as a non-zero exit with a clean "not found" error. This makes
delete --force safe to invoke from CI/CD and agent-driven pipelines where
the target may have been removed concurrently by another actor.
metrics: metrics instant now honors --profile and DASH0_PROFILE (#221)
Previously the command always resolved its API URL, auth token, and dataset
from the on-disk active profile, silently ignoring the per-invocation profile
selector. It now goes through the same context-carried configuration that
every other API-backed command uses.
skill: Add dash0 skill install and dash0 skill show, which distribute an Agent Skill teaching AI coding agents (Claude Code, Codex, Cursor, GitHub Copilot) this CLI's command surface without spending turns on --help exploration. (#212)
skill install detects the current agent host (Claude Code, Codex, Cursor, or GitHub Copilot) and installs a
SKILL.md plus reference docs into that host's conventional directory in the current project; skill show [topic]
prints the same content to stdout for CI or ephemeral sessions. Neither command calls the Dash0 API or requires
--experimental. In agent mode, a failing command now carries a follow-up hint pointing at dash0 skill install
when the skill isn't installed yet, or at dash0 skill show / dash0 --agent-mode --help when it is — so an
agent that mis-invokes has a concrete next step. Suppress with --no-skill-hint or DASH0_NO_SKILL_HINT=1;
explicit --no-skill-hint=false or DASH0_NO_SKILL_HINT=0 re-enables the hint on demand.teams: teams get -o json and teams get -o yaml now emit the TeamDefinitionV1Alpha1 envelope only, without the enriched members / dashboards / checkRules / syntheticChecks / views / datasets arrays (#200)
Prior versions emitted the enriched GetTeamResponse wrapper ({team, members, dashboards, ...}). The new output is the CRD envelope directly ({apiVersion, kind, metadata, spec}), so dash0 apply -f can round-trip the exported document without post-processing. spec.members renders as email addresses rather than internal user ids.
Scripts that read .team.metadata.labels["dash0.com/id"] or .team.spec.display.name need to drop the .team. prefix — e.g. .metadata.labels["dash0.com/id"], .spec.display.name. Scripts that consumed the enriched arrays (.dashboards[], .members[].spec.display.email, etc.) should use dash0 teams get <id> (the default table output) for a human-readable view, or dash0 teams list-members <id> for programmatic access to the member list.
The dash0 teams * command tree is gated behind --experimental and does not carry a stability guarantee, but this shape change is nevertheless disruptive enough to warrant an explicit callout.teams: Manage teams declaratively via teams create -f and apply -f on Dash0Team YAML (#200)
dash0 --experimental teams create -f <file> accepts a TeamDefinitionV1Alpha1 document. When the document carries a metadata.labels["dash0.com/origin"] label, the CLI upserts by origin (PUT, idempotent); otherwise it creates a new team (POST) and the server assigns id and origin.
dash0 apply recognizes kind: Dash0Team and routes it through the same upsert path, so team definitions round-trip through the standard export-edit-reapply GitOps workflow alongside other assets.
spec.members accepts either email addresses or internal member ids; the server resolves emails during reconciliation and rejects unresolvable ones with a single 400 listing every offender. The CLI renders team membership as emails on teams get, teams list-members, and the apply diff so review artifacts stay legible.
The existing imperative commands (teams create <name>, teams add-members, teams remove-members, teams update) are preserved and now accept emails or ids for member arguments.check-rules: Name check rules imported from a PrometheusRule CRD as <group name> - <alert name>, matching the Dash0 Kubernetes operator and Terraform provider (#182)
Previously the CLI named such check rules after the alert only, so the same CRD produced a different name than the operator and Terraform provider.
This affects check-rules create, check-rules update, and apply.
Check rule identity for upsert is the dash0.com/id / id, not the name, so for definitions that pin an identifier this is a non-destructive in-place rename surfaced as a one-line diff on the next apply.build: Add Nix flake packaging so the CLI can be installed and run on Nix and NixOS (#174)
The flake builds the CLI with buildGoModule, installs Bash, Zsh, and Fish
completions, and exposes nix run, nix profile install, an overlays.default
for NixOS and Home Manager, and a nix develop shell. Non-flake default.nix
and shell.nix shims are provided for systems without flakes enabled. A
homeManagerModules.default declares profiles under ~/.dash0: static tokens
are read from authTokenFile at activation time and OAuth profiles are seeded
for dash0 login, with runtime-acquired tokens preserved across rebuilds.
A pre-built binary is published to a Nix User Repository for a compile-free
install on small or non-x86_64 machines.homebrew: Resume publishing the Homebrew cask to the dedicated tap on every release (#175)
Tagged releases failed to update Casks/dash0.rb in dash0hq/homebrew-dash0-cli
because the release pipeline could not write to the tap repository, leaving cask
users pinned to a stale version. The cask is now published again on each release,
so brew upgrade --cask dash0 tracks the latest version.homebrew: Fix brew install --cask dash0hq/dash0-cli/dash0 failing on Linux (#172)
The generated Homebrew cask ran an unconditional postflight hook invoking the
macOS-only /usr/bin/xattr to strip the Gatekeeper quarantine attribute. On Linux
that tool does not exist, so the install aborted at the postflight step even though
the cask shipped correct Linux binaries. The hook is now guarded with if OS.mac?.failed-checks: Add dash0 failed-checks query command to query active and historical alerting issues (#92)
Supports filtering by --status critical,degraded, --active (unresolved only),
and generic --filter expressions using the same syntax as logs query and spans query.
Output formats: table (with semantic coloring for status), json, csv.
Customize the displayed columns with --column; any issue label (such as priority or owner)
can be used directly as a column name.
The list and ls aliases are available for backwards compatibility.spam-filters: Accept group-prefixed apiVersion values (e.g. operator.dash0.com/v1alpha1, dash0.com/v1alpha1) in spam filter YAML input (#169)
The CLI rejected spam filter documents exported from the Dash0 Kubernetes operator because they
carry a group-prefixed apiVersion. The CLI now normalizes these to the bare version before
dispatching, so operator-exported and canonical-form YAML files work with create, update, and apply.auth: Add dash0 login and dash0 logout for browser-based OAuth 2.0 + PKCE authentication (#27)
Profiles now have an explicit auth mode: static (long-lived auth_* token) or OAuth (browser flow).
Mark a new profile as OAuth at creation time with dash0 config profiles create <name> --oauth --api-url <url>,
then run dash0 login to obtain access and refresh tokens.
Access tokens are refreshed transparently before they expire; dash0 logout revokes them best-effort
and clears the tokens from the profile while keeping the profile shell for re-login.
Switch a profile between static and OAuth at any time with dash0 config profiles update <name> --oauth[=true|=false]
(the transition is destructive and prompts for confirmation unless --force is passed).
dash0 config profiles list gains an AUTH column showing the auth mode and remaining token lifetime,
and dash0 config show annotates the Auth Token: line with OAuth state.
dash0 login requires an interactive terminal — agent mode and non-TTY environments still use static tokens
via DASH0_AUTH_TOKEN or dash0 config profiles create --auth-token.
dash0 logout requires --force when invoked in agent mode (or when auto-detected via env vars like
CLAUDE_CODE), so an AI agent cannot silently revoke a profile's refresh token.
Telemetry send commands (dash0 logs send, dash0 spans send) refuse upfront when the active profile
is OAuth-typed, because the Dash0 OTLP ingress does not (yet) accept OAuth access tokens — only static
auth_* tokens. The error names the workarounds: pass --auth-token auth_<...> for the invocation,
set DASH0_AUTH_TOKEN, or convert the profile with dash0 config profiles update <name> --oauth=false.
Older dash0 CLI binaries from before OAuth support shipped (e.g. v1.12.0) do not understand
OAuth-typed profiles. dash0 config show and dash0 config profiles list silently render the
access token as if it were a static one (no (OAuth, ...) annotation), and any command that calls
the API fails with auth token must start with 'auth_' when the api-client library rejects the
dash0_at_* prefix. If you have multiple dash0 binaries installed (for example a homebrew-installed
dash0 alongside a development build) make sure every binary reading the profile is from this
release or later. Static-token profiles are unaffected.
otlp: Add dash0 otlp proxy, a long-running local OTLP forwarder that accepts OTLP/HTTP and OTLP/gRPC traffic and forwards every batch to Dash0 using the active profile's credentials. (#159)
The proxy binds 127.0.0.1:4318 (OTLP/HTTP) and 127.0.0.1:4317 (OTLP/gRPC) by default — an OpenTelemetry SDK at default endpoint configuration connects with no environment variable change.
It is gated behind -X (experimental) and is not intended as a replacement for the OpenTelemetry Collector.
See docs/commands.md for the full reference including the agent-mode event schema and failure-mode classification.
logs, spans, traces: Add --precision <adaptive|disabled> to logs query and spans query to select the API sampling mode for the request. traces get always disables adaptive sampling so the complete trace is returned. (#167)
Without the flag the API defaults to adaptive sampling, which samples telemetry data during query execution to keep queries fast on large datasets while returning statistically representative results.
Pass --precision disabled for the API equivalent of the Precision toggle in the Dash0 UI: every matching record is returned, at the cost of higher query latency on wide time ranges.
Use this for narrow lookups (e.g. test.id is <uuid>, trace.id is <hex>) that must be deterministic.
traces get always disables adaptive sampling — retrieving a trace must return every span in the trace regardless of query window, so the flag is not exposed on that command.
homebrew: Homebrew distribution is moving to a dedicated tap at dash0hq/homebrew-dash0-cli and switching from a formula to a cask. (#82, #162)
Starting with the next release, new users install with:
brew install --cask dash0hq/dash0-cli/dash0 — no brew tap, no brew trust.
Existing tap users will see a deprecation warning on brew upgrade dash0
pointing at the new install path. The formula-to-cask switch follows
Homebrew's convention for pre-built binary CLIs and aligns with
goreleaser's deprecation of its brews: configuration. See
docs/brew-tap-migration-2026-06.md for the full migration guide.
notification-channels: surface the Dash0 web app deep link in notification-channels list and notification-channels get (#147)
The list table and CSV output now include a URL column with a direct link
to the channel in the Dash0 web app. The get table output prints the same
URL as a new URL: field.config: Rename DASH0_RETRY_COUNT to DASH0_MAX_RETRIES and add --max-retries global flag (#141)
The environment variable DASH0_RETRY_COUNT has been renamed to DASH0_MAX_RETRIES for consistency with the Terraform provider.
A new --max-retries global flag is now available on all commands as an alternative to the environment variable.
Resolution order: --max-retries flag, then DASH0_MAX_RETRIES env var, then default (3).send-log-event action: Fix send-log-event action ignoring connection inputs when a profile already exists (#143)
When a profile already existed (e.g., from the setup action), the action skipped profile creation
and ignored any otlp-url, auth-token, or dataset inputs. The action now updates the existing
profile with the provided values.