48.9k Log in Get started
Dashboard

What goes in a DevOps dashboard in Metabase?

A DevOps dashboard is the daily instrument panel for delivery ops: pipeline success rate, deploys per day by environment, rollbacks, environment health, incident load, and the toil that eats the team's week. It sits between the research-benchmark DORA dashboard and the CI-internals view in CI pipeline health, and links to both.

For: platform and DevOps engineers, SREs, and team leads. Grain: daily for pipelines and deploys, weekly for rollbacks and toil. Refresh: hourly — real-time paging stays in the on-call stack.

What does a DevOps dashboard look like?

Here’s the layout this guide builds. The KPI row and attention card give the morning-standup read; pipelines and deployments come next because that’s where a bad day announces itself; stability and toil sit at the bottom, ending in a table of recent rollbacks with their causes — the card people actually argue about.

DevOps dashboard in Metabase showing pipeline success rate, deploys by environment, rollbacks, uptime, incidents, and toil.
An example DevOps dashboard in Metabase, built from CI/CD and incident data. Figures are illustrative.

Which cards belong on a DevOps dashboard?

The eight below cover the three questions delivery ops asks daily: is the pipeline healthy, are deploys landing safely, and what is quietly burning the team’s time.

  • Pipeline success rate, daily, with a goal line (line)
  • Deploys per day by environment — production, staging, dev (stacked bar)
  • Rollback rate per week, as a share of production deploys (bar)
  • Environment health — uptime by environment (line)
  • Incidents opened vs. resolved per week (bar)
  • Mean time to recovery, weekly (line)
  • Manual interventions per week — the toil indicator (bar)
  • Recent rollbacks and failed deploys, with cause and recovery time (table)

What data does the dashboard need?

  • A pipeline_runs table — started_at, status, environment, triggered_deploy, rolled_back — from your CI/CD tool’s API or webhooks.
  • A deployments table with service, environment, version, and outcome, including a rollback flag and cause written at rollback time.
  • An incidents table with opened_at, resolved_at, and severity, from PagerDuty or your incident tool.
  • Per-environment uptime rollups from your monitoring stack, snapshotted into the warehouse.
  • A toil log — manual re-runs, hands-on deploy steps, runbook executions — countable from CI events and on-call annotations.

How do you build it?

  1. Ship pipeline and deploy events from GitHub Actions, GitLab, or CircleCI into your warehouse — webhooks into a raw events table is enough to start.
  2. Define the rollback rule in a shared model — a rolled_back flag set at rollback time, with a cause — so the rate is computed one way everywhere.
  3. Join incident data from PagerDuty on service and time, and snapshot per-environment uptime from your monitoring stack.
  4. Build the KPI scalars production-only, then the daily and weekly charts against the shared models, keeping staging and dev visible only in the stacked deploy chart.
  5. Add filters for environment, service, and date range — defaulting the environment filter to production — and set the dashboard to hourly refresh.

Example card SQL

Daily pipeline success, deploys, and rollback rate by environment PostgreSQL 
SELECT
date_trunc('day', r.started_at)                       AS day,
r.environment,
COUNT(*)                                              AS pipeline_runs,
ROUND(
  100.0 * COUNT(*) FILTER (WHERE r.status = 'success')
    / NULLIF(COUNT(*), 0), 1
)                                                     AS success_rate_pct,
COUNT(*) FILTER (WHERE r.triggered_deploy)            AS deploys,
COUNT(*) FILTER (WHERE r.rolled_back)                 AS rollbacks,
ROUND(
  100.0 * COUNT(*) FILTER (WHERE r.rolled_back)
    / NULLIF(COUNT(*) FILTER (WHERE r.triggered_deploy), 0), 1
)                                                     AS rollback_rate_pct
FROM pipeline_runs r
WHERE r.started_at >= now() - interval '14 days'
GROUP BY 1, 2
ORDER BY 1, 2;

Metrics

Deployment frequency Change failure rate MTTR Build success rate

Integrations

GitHub + Metabase GitLab + Metabase CircleCI + Metabase PagerDuty + Metabase

Dashboards

DORA metrics CI pipeline health Software delivery Incident response

FAQ

What is a DevOps dashboard?
A DevOps dashboard is the day-to-day operational view of your delivery machine: are pipelines passing, how often are you deploying and where, how often do deploys get rolled back, are the environments healthy, and how much manual toil is the team absorbing. It runs at daily and weekly grain and gets checked every morning — unlike a DORA dashboard, which is a monthly research-benchmark view, this one exists to catch this week's problems.
How is this different from a DORA dashboard?
DORA's four keys are a quarterly benchmark: they tell you how your org compares to industry research, at monthly grain, and they deliberately exclude the operational texture. A DevOps dashboard is the daily instrument panel — staging deploys, pipeline failures, manual interventions, rollbacks per week — most of which DORA never counts. Keep both: the DORA dashboard for the quarterly conversation, this one for standup. If a number appears on both, define it once in a shared model so they cannot drift apart.
How is this different from a CI pipeline health dashboard?
A CI pipeline health dashboard stays inside the pipeline: queue time, duration by stage, flaky tests, runner utilization. This dashboard treats CI as one card among six and adds what happens after the merge — deploys by environment, rollbacks, environment uptime, incident load, and toil. If your pipeline success rate here looks bad, the CI dashboard is where you go next; the two link to each other rather than repeating each other's charts.
What counts as a rollback, and how do I track it?
Decide once, in the model: a rollback is any action that returns production to a previous version because of the deploy — a revert deploy, a re-deploy of the prior artifact, or a feature-flag kill switch used as an emergency exit. Tag it in the deploy record at the moment it happens (a rolled_back flag plus a cause) rather than reconstructing it later from Git archaeology. The rate that matters is rollbacks per production deploy, weekly — a raw count just grows with deploy volume.
How do I measure toil without surveilling engineers?
Count events, not people. Good toil signals are manual pipeline re-runs, deploys that needed a human in the loop, pages that required hands-on-keyboard work, and recurring runbook executions — all countable from your CI and incident tooling without attributing them to individuals. The chart's job is to justify automation work: when the same failed migration step causes twelve re-runs in a week, that is a script waiting to be written, and the dashboard is the evidence.
Should staging and dev deploys be on the same dashboard as production?
Yes, but never in the same number. A stacked bar of deploys by environment is useful precisely because it shows the pipeline's whole throughput — a healthy setup deploys to dev and staging several times more often than to production, and a shrinking staging share predicts production surprises. But every KPI scalar at the top should be production-only, and the environment filter should default to production, so nobody quotes a number that quietly includes dev.
What refresh rate does this dashboard need?
Hourly is the sweet spot. The dashboard answers "how is delivery going this week", not "is production down right now" — paging and real-time alerting belong to your monitoring stack, and duplicating them in a BI tool builds a slower pager. Set the dashboard to refresh hourly, or every 15 minutes if it lives on a team wall display, and let PagerDuty or your on-call tooling own the real-time path.