48.3k Log in Get started
Dashboard

What does an alert quality dashboard show in Metabase?

An alert quality dashboard shows whether monitors page for real problems or train responders to ignore them. It combines alert and monitor data from tools such as PagerDuty, Grafana, Datadog, and Prometheus in one governed view.

For: SRE leads, on-call rotation owners, and platform teams.Grain: one row per alert firing, flagged with whether it became an incident.

Which cards belong on an alert quality dashboard?

  • Alerts fired per week by source (stacked bar)
  • Alert-to-incident conversion rate (number + trend)
  • Noisiest monitors — high volume, low conversion (table)
  • Auto-resolved alerts share (number)
  • Off-hours alerts per week (line)
  • Muted or silenced monitors inventory (table)
  • Repeat alerts on the same monitor within 24h (table)

What data does the dashboard need?

  • alerts with monitor/rule ID, service, severity, fired and resolved timestamps.
  • A became_incident flag — from the incident tool's alert-to-incident link, or a join on service and time window.
  • monitors (or alert rules) with owner, paused/muted state, and thresholds.

How do you build it?

  1. Sync alert events and monitor metadata into a database or warehouse.
  2. Link alerts to incidents — most incident tools record the triggering alert; otherwise join on service and time proximity, and caveat it.
  3. Exclude maintenance windows and test monitors from the noise math.
  4. Build the noisy-monitor table first — it's the card that drives cleanup work — then the volume and conversion trends.

Example card SQL

Noisiest monitors, trailing 90 daysPostgreSQL
SELECT
  monitor_name,
  service_name,
  COUNT(*) AS alerts_fired,
  COUNT(*) FILTER (WHERE became_incident) AS incidents,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE NOT became_incident)
    / NULLIF(COUNT(*), 0), 1
  ) AS noise_rate
FROM alerts
WHERE fired_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY monitor_name, service_name
HAVING COUNT(*) >= 5
ORDER BY noise_rate DESC, alerts_fired DESC
LIMIT 25;

Metrics

Alert noise rateIncident countMean time to acknowledge

Integrations

PagerDuty + MetabaseGrafana + MetabaseDatadog + MetabasePrometheus + Metabase

Dashboards

Incident responseSLO tracking

FAQ

What is an alert quality dashboard?
An alert quality dashboard measures whether your monitors page for real problems — alert volume, the share of alerts that became incidents, and the specific monitors generating noise. Monitoring tools like Grafana and Datadog fire the alerts; this dashboard sits on top of their history in a database and reports the alert noise rate, so cleanup work targets the noisiest monitors instead of anecdotes.
What data sources feed an alert quality dashboard?
Alert and monitor records from wherever paging happens: PagerDuty alert events, Grafana alert rule history, Datadog monitor events, and Prometheus Alertmanager notifications. Land them in an alerts table with a became_incident flag — from the incident tool's alert-to-incident link where it exists — plus a monitors table with owner and muted state.
What is a good alert-to-incident conversion rate?
There's no universal number — direction matters more than level. If most alerts never become incidents, tighten thresholds or delete monitors; if nearly all do, you may be under-monitoring and finding out from users instead. Track the inverse as the alert noise rate, watch its trend per team and per source, and pair it with incident count so a "quieter" pager isn't just missed coverage.
How do you reduce alert noise?
Work the noisy-monitor table, not the whole alert stream. Sort monitors by volume and conversion rate, then fix the top offenders one at a time: tighten thresholds, add for-durations so flapping settles before paging, route low-urgency alerts to tickets instead of pages, and delete monitors nobody acts on. Re-check the noise rate and off-hours page counts a few weeks later — sustainable on-call shows up in the incident response dashboard too.
Why track muted monitors?
A muted monitor is a decision someone made under pressure and forgot. The inventory card surfaces silenced coverage so each mute gets fixed or deleted deliberately — otherwise the gap resurfaces as an unmonitored outage, discovered by users instead of a page. Review the list in the same weekly pass as the noisy-monitor table, and check MTTA for the services involved: muted coverage often shows up first as slower acknowledgment.