What goes in a release management dashboard in Metabase?

A release management dashboard watches the process of shipping: calendar adherence, readiness checklist status, scope change after the cut, deployment windows, hotfixes and rollbacks per release, and approvals cycle time. It is the process twin of release quality, which tracks the defect outcomes of what shipped.

What does a release management dashboard look like?

Here’s the layout this guide builds. The train’s vital signs and the attention card sit on top; schedule and scope come next — adherence, post-cut churn, and the readiness of the next release; stability and process close the page with hotfixes, deployment windows, and the upcoming release table the weekly meeting runs from.

Which cards belong on a release management dashboard?

The eight below cover the release manager’s three questions: is the train on schedule, is the next departure ready, and what did the last few departures cost.

• On-time vs. slipped releases by month (stacked bar)
• Scope change after cut, per release — issues added and removed (grouped bar)
• Releases per month, with month-over-month comparison (trend)
• Next release readiness — checklist items complete against total (progress)
• Approvals cycle time, median days per week (line)
• Hotfixes and rollbacks per release (grouped bar)
• Deploys by weekday and window — in-window vs. outside (stacked bar)
• Upcoming releases — target date, owner, status, checklist, approvals (table)

What data does the dashboard need?

• A releases table with release_name, target_date (frozen at planning), cut_at, shipped_at, and a slip-reason category.
• Issue-tracker rows linked to a release, with added_after_cut and removed_after_cut flags derived from the cut timestamp.
• Readiness checklist items per release — item, owner, completed flag — from a queryable tracker template.
• Approval events with requested and granted timestamps, per approval type.
• Deploy logs with timestamps and a hotfix/rollback flag, for windows and the stability cards.

How do you build it?

1. Create the release dimension first — name, frozen target date, cut date, ship date — and make every other table join to it; this is also what lets this dashboard link to release quality per release.
2. Derive scope-churn flags by comparing each issue’s link and unlink timestamps from Linear or your tracker to the release’s cut date.
3. Land approval events with requested and granted timestamps, and compute the weekly median in a model rather than in each card.
4. Mark hotfix and rollback deploys in the deploy log at the moment they happen, then build the per-release stability chart from it.
5. Add filters for product, release train, and date range, and put the upcoming-releases table on the weekly release meeting’s agenda — the dashboard replaces the status spreadsheet, not the meeting.

Example card SQL

SELECT
r.release_name,
r.target_date,
r.shipped_at::date                                    AS shipped_date,
(r.shipped_at::date <= r.target_date)                 AS on_time,
COUNT(i.id) FILTER (WHERE i.added_after_cut)          AS issues_added_after_cut,
COUNT(i.id) FILTER (WHERE i.removed_after_cut)        AS issues_removed_after_cut,
ROUND(
  100.0 * COUNT(i.id) FILTER (WHERE i.added_after_cut)
    / NULLIF(COUNT(i.id) FILTER (WHERE NOT i.removed_after_cut), 0), 1
)                                                     AS scope_added_pct,
COUNT(h.id)                                           AS hotfixes,
COUNT(h.id) FILTER (WHERE h.was_rollback)             AS rollbacks
FROM releases r
LEFT JOIN release_issues i ON i.release_id = r.id
LEFT JOIN hotfixes h        ON h.release_id = r.id
WHERE r.shipped_at >= now() - interval '6 months'
GROUP BY r.id, r.release_name, r.target_date, r.shipped_at
ORDER BY r.shipped_at;

Related

Metrics

Integrations

Dashboards

FAQ