48.3k Log in Get started
Metric · Observability

What is incident count, and how do you measure it in Metabase?

Incident count is the number of qualifying incidents in a period, segmented by severity and service. It's the volume half of incident health — pair it with MTTA and MTTR to see whether load and response are moving together. Measure it in Metabase from incident records synced from PagerDuty, Datadog, or Kibana cases.

TL;DR — Count rows in incidents per period, split by severity and service. The hard part isn't the SQL — it's agreeing once on what qualifies as an incident.

What incident count measures

It measures how often things break badly enough that a human had to respond. Trending it by severity and service shows whether reliability work is paying off and which services generate the load. The absolute number means little on its own — definitions vary too much between teams — but the trend and the distribution are decision-grade.

What data does it need?

  • An incidents table: created_at, severity, service_id, status, and environment.
  • A written qualifying rule: which severities, which sources, and whether auto-resolved pages count.
  • Source: PagerDuty, Datadog incidents, Kibana cases, incident.io, or labeled issues with open timestamps.

SQL patterns

Incidents per week by severityPostgreSQL
SELECT
  date_trunc('week', created_at) AS week,
  severity,
  COUNT(*) AS incidents
FROM incidents
WHERE environment = 'production'
GROUP BY 1, 2
ORDER BY 1, 2;
Incident load by servicePostgreSQL
SELECT
  service_name,
  COUNT(*) AS incidents,
  COUNT(*) FILTER (WHERE severity IN ('sev1', 'sev2')) AS high_severity,
  COUNT(*) FILTER (
    WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
  ) AS last_30_days
FROM incidents
WHERE created_at >= CURRENT_DATE - INTERVAL '180 days'
GROUP BY service_name
ORDER BY incidents DESC;

Pitfalls

Counting alerts as incidents.→ Alerts are notifications; incidents are events a human worked. Mixing them rewards noisy monitors — track the alert noise rate separately.
Comparing teams with different qualifying rules.→ A team that files a Sev-3 for every blip will always look worse than one that doesn't. Normalize the definition before comparing.
Treating fewer incidents as automatically better.→ Zero incidents can mean great reliability — or under-reporting. Pair the count with detection sources and postmortem culture.
Ignoring severity mix.→ Ten Sev-4s and one Sev-1 are different weeks. Always segment; never report a single undifferentiated number.

Where this metric applies

Metrics

Mean time to acknowledgeMTTRAlert noise rateSLO compliance

Dashboards

Incident response dashboardAlert quality dashboard

FAQ

What counts as an incident?
Whatever your written definition says — that's the point. A common baseline: an unplanned event that degraded service for users and required human response. Agree on it once, encode it in the incidents model, and apply it everywhere. Keep alerts out of the count — pages that led nowhere belong in the alert noise rate — and publish the rule next to the incident response dashboard so the numbers stay comparable over time.
Should auto-resolved incidents count?
Usually as their own category. They carry signal about flapping systems and noisy thresholds, but mixing them with human-worked incidents distorts both the count and response-time metrics like MTTA and MTTR. Add an auto_resolved flag to the incidents table so dashboards can include or exclude them deliberately, and treat a rising auto-resolve share as an input to the alert noise rate cleanup list.
Is incident count a team performance metric?
No — punishing high counts teaches people to stop filing incidents, which destroys the data. Use it to direct reliability investment instead: trend it by severity and service on an incident response dashboard, pair it with MTTR to see whether load and recovery are moving together, and let the per-service distribution decide where the next reliability sprint goes.
How do you track incident count in Metabase?
Sync incident records from PagerDuty, Datadog, or Kibana cases into a SQL database with created_at, severity, service_id, and environment columns. Count rows per week with date_trunc, split by severity and service, and pin the results to an incident response dashboard next to MTTA and MTTR so volume and response read as one picture.
What is the difference between incident count and alert count?
Alerts are notifications from monitors; incidents are events a human actually worked. One incident can produce dozens of alerts, and a noisy monitor can fire for weeks without a single real incident. Count them separately: incident count measures reliability load, while the alert noise rate — alerts that never became incidents — measures paging health. Mixing the two rewards noisy monitors and hides both signals; the alert quality dashboard keeps them side by side.