Dashboards were the last part of Helix still living entirely in a UI, edited by whoever got there first. Not anymore.

Every other artifact in a Helix workspace — alert rules, sampling policies, routing — has had a text representation for a year. Dashboards didn't, and it showed: teams kept two or three near-duplicate dashboards because nobody was sure who owned the canonical one, and a well-meaning edit during an incident would silently break a panel for everyone else.

The .hxdash format

A dashboard is now a plain YAML file, one panel per HelixQL query, checked into whatever repo you already keep your infra config in:

title: Checkout API — golden signals
panels:
  - name: p95 latency
    query: from traces | where route == "/checkout" | summarize p95(duration) by bin(5m)
    type: timeseries
  - name: error rate
    query: from traces | where route == "/checkout" | summarize errors=countif(status=="error") / count() by bin(5m)
    type: timeseries

CI review before it hits production

Because it's a file, it goes through the same pull request your team already uses for everything else. Reviewers see the actual query diff, not a screenshot. We added a hx dashboards apply CLI command that diffs the file against the live dashboard and applies only the delta, and a --dry-run flag that lints panel queries against your schema before anything touches production.

What this replaced

Internally, this killed a Slack ritual we didn't love: pinging #observability to ask "can someone fix the panel on the payments dashboard, it's querying the old field name." Now that's a two-line PR with a git blame.

Importing what already exists

We didn't want teams to have to choose between the old workflow and the new one on day one, so the migration path matters as much as the format itself. Running hx dashboards export against any UI-built dashboard produces a ready-to-commit YAML file, diffed against nothing so the first commit is just "here's what already existed." From there, every subsequent change goes through review like any other file in the repo, and teams have told us the export step alone was often enough to surface dashboards that had drifted from what anyone thought they showed.

  • Dashboards as versioned YAML, one file per dashboard
  • hx dashboards apply CLI with dry-run linting against your schema
  • Pull-request review on every dashboard change, same as code
  • Import existing UI-built dashboards to YAML with one command