The dashboard belongs with the code

A good dashboard usually begins as a question.

Why did checkout slow down? Are the workers keeping up? Is this new release using twice the memory, or does the graph merely look dramatic because somebody changed the time range?

You answer the question, tidy the panels, give the dashboard a sensible name — and a small piece of operational knowledge now lives inside one Grafana workspace. The application continues through staging, production, and review apps. The dashboard stays where it was born. Six months later, nobody is quite sure whether the copied version is current or whether editing it will erase somebody else’s useful work.

We think the dashboard belongs with the code that gives it meaning.

Starting today, Watasu can synchronize Grafana dashboards directly from your repository.

A folder is the whole convention

Export a dashboard from Grafana, put its JSON under .watasu/dashboards, and commit it:

.watasu/
└── dashboards/
    ├── overview.json
    └── api/
        ├── latency.json
        └── errors.json

That is all the configuration there is. There is no observability manifest to maintain and no environment switch to remember. After each successful release, Watasu reconciles those files into the app’s Grafana workspace.

Directories stay useful on the other side: api/latency.json lands in an api folder in Grafana. You can arrange dashboards around services, teams, or the questions they answer without flattening everything into one long list.

Each dashboard keeps a stable Grafana uid, which makes updates pleasantly ordinary. Change a panel and deploy; the existing dashboard changes in place. Remove a repository dashboard and Watasu removes that managed dashboard on the next successful release. Dashboards created by hand with other UIDs are left alone.

Data sources without workspace archaeology

An exported Grafana dashboard normally remembers the exact UID of the data source it was using. That is useful inside one workspace and awkward everywhere else: staging Metrics and production Metrics are different data sources, even when they answer the same PromQL.

Repository dashboards can use portable Watasu placeholders instead:

$watasu.metrics
$watasu.runtime
$watasu.object.storage
$watasu.logs
$watasu.traces

Watasu binds each placeholder to the matching data source attached to that app. The dashboard can move with the release while its queries continue to look at the right environment.

This is particularly nice for review apps. If a review app has Grafana, the dashboards in that review release appear there too, pointed at that review app’s data. A performance panel can travel alongside the branch whose performance you are inspecting.

Grafana remains an explicit app capability

Dashboard files do not quietly provision infrastructure.

If an app does not have Grafana, its build and release still succeed and no dashboard resources are created. Attach Grafana later — usually by attaching Logs, Metrics, or Traces — and Watasu applies the dashboard bundle from the current release. The release keeps the exact bundle that shipped with it, rather than reaching back into a moving branch.

That boundary matters: repositories describe the dashboards they want, while the app still decides whether it has an observability workspace at all.

It also means there is no second deployment mode to learn. Repository dashboards are simply active for every app or review app that has Grafana, and inactive where Grafana does not exist.

Available now

Repository dashboards are live today for every Watasu app with Grafana. Export one useful dashboard, give it a stable uid, replace workspace-specific data source UIDs with the Watasu placeholders, and place it under .watasu/dashboards.

The observability documentation covers the file rules, data source placeholders, limits, updates, and removals.

Dashboards are a form of shared memory. We are happy they can finally live somewhere your team already reviews, versions, and carries from one release to the next.

If you build a dashboard that every service should inherit, we would love to hear what question it answers — info@watasu.io.