48.3k Log in Get started
Dashboard

What does a release quality dashboard show in Metabase?

A release quality dashboard shows whether each release makes the error picture better or worse — new error groups per release, error rates, regressions, and the deploys that had to be rolled back. It joins error data from tools such as Sentry and Raygun with deploy records from Vercel, GitHub, or GitLab.

For: Engineering leads, release owners, and QA. Grain: one row per release (or deploy), joined to error rollups and incidents.

Which cards belong on a release quality dashboard?

  • Error rate by release (bar)
  • New error groups introduced per release (table)
  • Crash-free sessions or users by release (line)
  • Regressed error groups — resolved, then back (table)
  • Deployments per week with failures and rollbacks (combo)
  • Change failure rate (number + trend)
  • Time from release to first error spike (table)

What data does the dashboard need?

  • releases (or deployments) with version, timestamp, environment, and status — plus session counts if the source tracks them.
  • error_rollups tagged with a release ID — the join that makes per-release error rates possible.
  • error_groups with first-seen and resolved timestamps for regression detection.
  • Optional incidents linked to the triggering deploy.

How do you build it?

  1. Tag errors with releases in the source SDK (Sentry and Raygun both support it) — without the tag, this dashboard can't exist.
  2. Sync releases, error groups, and rollups into a database (see the Sentry guide for routes).
  3. Join deploys from your delivery stack for change failure rate and rollback tracking.
  4. Build the per-release table first, then trends; annotate spikes with the release that shipped them.

Example card SQL

Error load by releasePostgreSQL
SELECT
  r.version AS release,
  MIN(r.released_at) AS released_at,
  COUNT(DISTINCT e.error_group_id) FILTER (
    WHERE g.first_seen_at >= r.released_at
  ) AS new_error_groups,
  SUM(e.event_count) AS error_events,
  ROUND(
    1.0 * SUM(e.event_count) / NULLIF(MAX(r.sessions), 0), 4
  ) AS errors_per_session
FROM releases r
LEFT JOIN error_rollups e ON e.release_id = r.id
LEFT JOIN error_groups g ON g.id = e.error_group_id
WHERE e.environment = 'production'
GROUP BY r.version
ORDER BY MIN(r.released_at) DESC
LIMIT 20;

Metrics

Error rateChange failure rateDeployment frequencyMTTR

Integrations

Sentry + MetabaseRaygun + MetabaseVercel + MetabaseGitHub + Metabase

Dashboards

Software deliveryIncident responseSLO tracking

FAQ

What is a release quality dashboard?
A release quality dashboard shows what each release did to production: new error groups introduced, error rate per release, crash-free sessions, regressions, and rollbacks. It joins error data from tools like Sentry and Raygun with deploy records, so "did the last release make things worse?" gets answered from data rather than gut feel — and change failure rate falls out of the same join.
What data sources feed a release quality dashboard?
Two sides of a join. Error data — releases, error groups, and rollups tagged with a release ID — comes from Sentry or Raygun. Deploy records come from Vercel, GitHub, or GitLab, with version, timestamp, environment, and status. Land both in a database as releases, error_groups, and error_rollups tables; the release tag on errors is the field that makes everything else possible.
How is this different from a software delivery dashboard?
The software delivery dashboard measures how fast and often you ship — pull requests, pipelines, and deployment frequency. Release quality measures what shipping did to production — errors, regressions, and rollbacks per release. They share the deploy table and meet at the DORA metrics: throughput comes from the delivery side, while change failure rate and MTTR need this dashboard's error and incident joins.
What if my errors aren't tagged with releases?
Fix that first — it's one SDK config line in Sentry or Raygun, and without the tag this dashboard can't attribute anything. Until it ships, you can approximate by time window: count error groups first seen in the 24 hours after each deploy. That misestimates slow-burn regressions and overlapping releases, so caveat the cards and treat the numbers as directional until real tagging lands.
How do you measure change failure rate from this data?
Define a failed change once — a deploy that was rolled back, hotfixed, or linked to an incident — then compute change failure rate as failed deploys over total deploys per period. The releases table provides the denominator; rollback status, incident links, and new-error-group spikes provide the numerator. Pair it with deployment frequency and MTTR to complete the DORA stability picture.