48.3k Log in Get started
Metric · Observability

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

MTTA — mean time to acknowledge — is how long it takes a responder to pick up an incident after it's created. It's the paging-health half of incident response: MTTR tells you how long recovery takes, MTTA tells you whether anyone answered the page. Measure it in Metabase from incident timestamps synced from PagerDuty or Datadog.

TL;DR — Incident created_at → acknowledged_at, reported as a median (and p90), not a mean. High MTTA usually means escalation policies, schedules, or alert fatigue — not slow engineers.

What MTTA measures

It measures the human front of the response pipeline: paging, escalation, and on-call attention. A rising MTTA with flat incident volume points at schedule gaps or alert fatigue; a healthy MTTA with terrible MTTR points the investigation at diagnosis and rollback instead.

What data does it need?

  • An incidents table with created_at and acknowledged_at (plus severity, service, and urgency for segmentation).
  • Source: PagerDuty incident log entries record the first acknowledge explicitly; most incident tools expose an equivalent.

SQL patterns

Median + p90 time to acknowledge by monthPostgreSQL
SELECT
  date_trunc('month', created_at) AS month,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (acknowledged_at - created_at)) / 60
  ) AS median_ack_minutes,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (acknowledged_at - created_at)) / 60
  ) AS p90_ack_minutes
FROM incidents
WHERE acknowledged_at IS NOT NULL
GROUP BY 1
ORDER BY 1;
Business hours vs. off hours (trailing 90 days)PostgreSQL
SELECT
  CASE
    WHEN EXTRACT(HOUR FROM created_at) BETWEEN 9 AND 17
      AND EXTRACT(ISODOW FROM created_at) < 6
    THEN 'business hours'
    ELSE 'off hours'
  END AS window,
  COUNT(*) AS incidents,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (acknowledged_at - created_at)) / 60
  ) AS median_ack_minutes
FROM incidents
WHERE acknowledged_at IS NOT NULL
  AND created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1;

Pitfalls

Reporting the mean.→ One unanswered 3 a.m. page skews the average for a month. Use the median and p90.
Including auto-acknowledged incidents.→ Bot or integration acks aren't response. Filter to human acknowledgments where the source distinguishes them.
Ignoring urgency and hours.→ A low-urgency ticket acknowledged next morning is fine; a Sev-1 shouldn't wait ten minutes. Segment by urgency and business hours.
Using MTTA to rank individuals.→ It measures the paging system — schedules, escalation, load — not personal diligence. Fix the system, not the people.

Where this metric applies

Metrics

MTTRIncident countAlert noise rate

Dashboards

Incident response dashboardAlert quality dashboard

FAQ

MTTA vs. MTTR — which matters more?
They diagnose different failures. MTTA isolates the paging and escalation layer — did anyone answer the page? MTTR covers the whole recovery, from failure start to service restored. A good MTTA with a bad MTTR means people answer fast but diagnosis or rollback is slow — a different fix entirely. Track both next to incident count on an incident response dashboard so load and response stay in one view.
What's a good MTTA?
For high-urgency pages, minutes — single digits with a working escalation policy. For low-urgency notifications, hours can be fine. Set targets per urgency level rather than one global number, and read the median and p90 rather than the mean: one unanswered 3 a.m. page skews an average for a month. If high-urgency MTTA drifts upward, check the alert noise rate first — alert fatigue is the usual culprit, and PagerDuty data shows both.
Why is our MTTA rising?
The usual suspects: alert fatigue from noisy monitors (check the alert noise rate), schedule gaps or timezone holes, and escalation policies that page the wrong people first. Segment MTTA by urgency, service, and business hours vs. off hours to localize it — a rise confined to off hours points at coverage, while a broad rise alongside a noisy alert quality dashboard points at fatigue.
How do you calculate MTTA?
Subtract the incident's creation time from its first human acknowledgment: acknowledged_at − created_at, aggregated per period. Despite the name, report it as a median — in SQL, percentile_cont(0.5) over the interval in minutes, with p90 alongside — because duration data is right-skewed. Exclude incidents that were never acknowledged or were auto-acknowledged by integrations. PagerDuty records the first acknowledge explicitly in incident log entries; Datadog exposes equivalent lifecycle timestamps.
How do you track MTTA in Metabase?
Sync incidents with created_at and acknowledged_at timestamps from PagerDuty or Datadog into a SQL database, then chart the monthly median and p90 with percentile_cont. Segment by urgency and business hours vs. off hours, and pin the result next to incident volume and MTTR on an incident response dashboard so paging health reads in context.