Recent changes and improvements to Dash0

As Dash0 grew, borders, panels and navigation started to compete with your dashboards, traces and logs for attention. The new layout uses spacing and surface levels instead of lines to group elements, so each page has less noise. Nothing has moved, so you don't need to relearn anything.

Until now, anyone who could read a dataset could change or delete every automation in it.

Now only admins and the people you share an automation with can edit or delete it, and everyone who can read the dataset can still read it. Select Share on an automation's page to give edit access to a member, a team, or every member. In Settings, each team and member page has a new Automations tab that lists the automations shared with them directly.

If you edited automations that someone else created, you can now only read them until someone shares edit access with you. The creator of an automation and admins keep their edit access.

Read the docs: Control Automation Sharing and Access

When you create an organization, the data storage region picker now offers AWS us-east-1 (N. Virginia) next to Oregon, Ireland, and the Netherlands. US customers had asked for an east-coast region.

Each region is a card showing the cloud it runs on, the place, and the cloud's own region ID. Dash0 stores that organization's telemetry in the region you pick, and you cannot change the region once the organization exists. Organizations that already exist keep the region they were created in.

See Organizations for the full region list and what the choice affects.

If your team keeps runbooks and agent skills in Git, next to the code they describe, Agent0 couldn't use them directly. Until now, bringing them to Agent0 meant copying each one into Dash0 by hand, and the copies drifted as soon as someone changed the original.

Now an admin can import them. In Organization Settings > Agent0 > Skills, select Import from Git. Scan any public GitHub or GitLab repository, or a private GitHub repository through the GitHub integration. Dash0 finds every SKILL.md, including skills with supporting files, and imports the ones you select. When a skill changes in the repository, select Update and Dash0 reads it again from the branch or tag you imported from.

Read the docs to import your first skills: Import Skills from a Git Repository

Telemetry from payment paths can carry cardholder data, such as a card number in a logged request body, a query string, or an exception message. Filtering it at the source is the strongest control, but a new service or a forgotten rule can still let one through.

Turn on Redact cardholder data for a dataset, and Dash0 detects likely card numbers in logs, spans, web events, and metrics before it stores them. Card numbers keep their first six and last four digits, such as 411111******1111. Verification codes, PIN blocks, and track data become <REDACTED>. Dash0 never drops a record, so traces and log searches keep working. Detection is pattern-based, so it does not catch encoded, encrypted, or split card numbers.

Two metrics, dash0.redaction.values_scanned and dash0.redaction.values_redacted, show what Dash0 scanned and what it redacted. See Redact Cardholder Data for what gets redacted, the limitations, and how to turn it on.

The new Forecast tab projects what you'll spend for a full billing cycle, based on your recent usage rate. Pick a baseline window and Dash0 scales that window's usage rate to a full cycle, then prices it against your org's real pricing tiers and any custom prices, the same way your invoice is calculated, broken down by SKU and dataset.

This is now the recommended way to estimate spend. See Forecast Your Spend to get started.

A failed CI run is usually the first sign that something is broken, but acting on it still takes a person. Someone has to notice the red build, open the logs, and work out what changed before anything gets fixed.

Automations now trigger on five GitHub Actions events: workflow runs, workflow jobs, manual workflow dispatches, check runs and check suites. Scope any of them by organization, repository, branch or workflow name, and filter by conclusion or status, so an automation starts on the failures you care about and stays quiet for everything else. From there the automation picks up the failed run, works out why it broke, and can push a fix so the workflow runs again. See the documentation to set one up.

Most teams know, deep down, that they should have service level objectives. Far fewer actually do, because getting there is a whole project. You have to agree on what to measure, write the queries behind it, tune the thresholds, and hope you picked the right ones.

Dash0 now paves for you the road to SLOs. Find SLOs under Alerting, point one at any signal you already send, and you get two numbers: how much failure you can still afford this month, and how fast you are using it up. Agent0 drafts the definition if you are not sure what to measure. One click turns the SLO into an alert, so you find out before the month is gone.

Read the documentation to set up your first one.

Yours to keep

Define your SLOs in Dash0, or keep them in your repository and apply them with the CLI or Terraform (and soon the Operator for Kubernetes). True to our commitment to open standards, we use OpenSLO as the serialization format, the same way we use OpenTelemetry for telemetry, Perses for dashboards, and PromQL for queries. This enables you to define your service levels with zero vendor lock-in.

Starting with version 0.155.0, the Dash0 Operator is compatible with OpenShift and can be installed via Helm as usual.

To do this, set operator.openShift.enabled to true. The operator will then deploy the required SecurityContextConstraints resource, allowing its components to run with the privileges they need to function correctly.

For more information, see the official documentation.

When you're doing GitOps and you're deleting a dashboard, check rule, or any other asset from your repo, it should disappear from Dash0, too. Wiring that kind of cleanup into a GitHub Actions workflow took a significant effort, since the right way to do it changes depending on what triggered the CI run.

The new sync-assets action handles that for you. Add it to a workflow (see the documentation), and it keeps assets in sync on every push, manual run, and scheduled run, with no additional tooling or state management needed.

What changed

Agent0 automations now follow the same permission model as dashboards. Anyone with read access to a dataset can create automations in it, and can edit and delete the automations created there, including ones somebody else made.

Automations managed as code through the API or Terraform stay read-only in Dash0. Update those at their source and apply again. Everyone can still read them, and administrators can delete them. To narrow or extend access on a single automation, use the Permissions section of its general settings.

Why this matters

Creating an automation used to need a separate dataset permission that, in practice, only administrators held.

Read more in Configure general settings and Access Control.

Not every question deserves the same model. Reading one service's error logs is cheap work. Chasing a symptom across four services during an incident is not, and answering it with a model that cannot hold the whole picture wastes more than credits. Until now Agent0 made that call for you, on every run, with no way to change it.

Agent0 now offers four levels, Light, Standard, Advanced, and Premium, plus a reasoning effort that controls how long the model thinks before it answers. Pick one in the Chat prompt toolbar, store one on an automation, name one on an MCP runTask call, or set your own default for each of those under Settings → Agent0. Slack answers say which level and effort they ran with and link to the Slack default in settings. A level names a capability step rather than a model, so Dash0 keeps the model behind each one current and your setting keeps meaning what you chose. Credits are charged on what a turn consumed, priced at the model that served it, so the cost of a level is the cost of the run and not a flat surcharge. Each answer reports the level and effort it ran with. See Model Selection.

One thing to know before your next invoice. Agent0's default level is now Advanced, up from the single model every run used before. It answers harder questions on the first pass, and it uses more credits per turn than the old default did. If your work is mostly routine triage, set your Agent0 Chat and Automations defaults to Light or Standard under Settings → Agent0 and keep the old cost profile. Every run shows its real credit cost, and a monthly credit budget still caps the total.

Not every level runs in every region. A level Dash0 cannot serve for your organization is disabled in the picker with the reason.