48.3k Log in Get started
Dashboard

What does an incident response dashboard show in Metabase?

An incident response dashboard shows whether failures get acknowledged and resolved fast enough, and whether the pager load is sustainable. It combines incident records from tools such as PagerDuty, Datadog, and Kibana cases in one governed view.

For: SREs, on-call engineers, engineering managers, and service owners. Grain: one row per incident, with created, acknowledged, and resolved timestamps.

Which cards belong on an incident response dashboard?

  • Incidents per week by severity (stacked bar)
  • Median time to acknowledge (MTTA) with p90 (line)
  • Median time to resolve (MTTR) with p90 (line)
  • Open incidents right now by severity (number)
  • Incidents by service, trailing 90 days (bar)
  • Pages per on-call shift and off-hours pages (bar)
  • Escalation rate — incidents needing a second responder
  • Postmortem completion for high-severity incidents

What data does the dashboard need?

  • incidents with stable ID, service, severity, created, acknowledged, and resolved timestamps.
  • incident_log_entries (or equivalent lifecycle events) for escalations and reassignment analysis.
  • services with owners and teams, so incident load lands on the right roadmap.
  • Optional on-call schedule data for pages-per-shift and off-hours load.

How do you build it?

  1. Sync incidents and lifecycle events into a database or warehouse (see thePagerDuty guide for routes).
  2. Normalize severity values and define which records count as qualifying incidents — exclude test and duplicate pages.
  3. Compute durations only from records with both timestamps; exclude open incidents from MTTA/MTTR math.
  4. Build summary cards, per-service drill-throughs, and severity/service filters.

Example card SQL

Incidents with median MTTA and MTTR by monthPostgreSQL
SELECT
  date_trunc('month', created_at) AS month,
  COUNT(*) AS incidents,
  COUNT(*) FILTER (WHERE severity IN ('sev1', 'sev2')) AS high_severity,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (acknowledged_at - created_at)) / 60
  ) AS median_ack_minutes,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (resolved_at - created_at)) / 60
  ) AS median_resolve_minutes
FROM incidents
WHERE resolved_at IS NOT NULL
GROUP BY 1
ORDER BY 1;

Metrics

Incident countMean time to acknowledgeMTTRAlert noise rate

Integrations

PagerDuty + MetabaseDatadog + MetabaseSentry + MetabaseKibana + Metabase

Dashboards

Alert qualitySLO trackingSoftware delivery

FAQ

What is an incident response dashboard?
An incident response dashboard is a governed reporting view of how failures get handled — how many incidents occur, how fast they are acknowledged and resolved, and who carries the pager load. Unlike the live triage screens in PagerDuty or Datadog, it works on incident history in a database, so MTTA, MTTR, and volume trends can be reviewed weekly and shared beyond the on-call team.
What data sources feed an incident response dashboard?
Any tool that records incidents with lifecycle timestamps. The common sources are PagerDuty incidents and log entries, Datadog incident management, and Kibana cases — synced into an incidents table with created, acknowledged, and resolved timestamps, plus a services table for ownership. Deploy records from GitHub or GitLab are worth adding early: they turn the same data into change failure rate.
Should MTTA and MTTR be means or medians?
Medians, with p90 alongside. Response and recovery times are heavily right-skewed — one multi-day incident wrecks an average and hides the typical experience. Report the median as the headline for MTTA and MTTR, keep p90 next to it so the tail stays visible, and compute both only from incidents that have the relevant timestamps.
What counts as an incident vs. an alert?
Define it once: an incident is a qualifying event a human acknowledged and worked, an alert is a notification that may or may not become one. Track the gap explicitly as the alert noise rate, and give alert volume and conversion their own alert quality dashboard — mixing the two grains inflates incident count and makes trends useless.
How often should incident metrics be reviewed?
Two cadences work well. Weekly, in the on-call handoff or ops review: open incidents, pages per shift, and anything breaching MTTA targets — the operational view. Monthly or quarterly, with engineering leadership: incident count and MTTR trends by service, postmortem completion, and whether reliability investment is working — alongside SLO tracking and error budgets.