Skip to main content
MTTA (mean time to acknowledge) measures how long it takes a responder to acknowledge an alert after it fires. MTTR (mean time to resolve) measures how long it takes to fully restore service after an incident begins. MTTA captures the speed of your paging and on-call process; MTTR captures the effectiveness of your entire response, from detection through fix. Both are averages calculated across incidents over a period.

​
Comparison at a glance

​
What is MTTA?

MTTA is the average time between an alert firing and a human acknowledging it. The formula: MTTA = (sum of time-to-acknowledge across all alerts) ÷ (number of alerts) If your team acknowledged 40 alerts this month and the acknowledgment times sum to 120 minutes, MTTA is 3 minutes. A rising MTTA usually points to problems upstream of the actual fix: alerts routed to the wrong team, escalation policies with gaps, notification channels people ignore, or plain alert fatigue from too many low-value pages. MTTA is the clearest single signal of whether your on-call setup is working.

​
What is MTTR?

MTTR is the average time from the start of an incident to full resolution: MTTR = (sum of time-to-resolve across all incidents) ÷ (number of incidents) If you had 5 incidents this quarter totaling 10 hours of downtime, MTTR is 2 hours. MTTR spans everything: detection, acknowledgment, triage, diagnosis, mitigation, and verification. That breadth makes it a useful executive-level indicator of reliability, but a blunt diagnostic tool — a bad MTTR tells you something is slow without telling you what.

​
What does the R in MTTR actually stand for?

MTTR’s “full form” is genuinely ambiguous, and the ambiguity matters when comparing numbers across teams:
  • Mean time to resolve — through full resolution, including any follow-up work. The most common meaning in incident management.
  • Mean time to recovery (or restore) — until service is back for users, even if a permanent fix comes later. Used by DORA metrics (“time to restore service”).
  • Mean time to repair — a hardware and manufacturing term for the time to physically fix a failed component.
Before you benchmark against another team’s MTTR or set a target, agree on which definition your clock stops at. A team measuring “recovery” (mitigation) will always look faster than a team measuring “resolution” (permanent fix), even with identical performance.

​
When should you track MTTA vs MTTR?

Track both — they answer different questions. Use MTTA to tune the front of your pipeline: if MTTA is high, fix routing, escalation, and alert noise before touching anything else, because nobody can resolve an incident they haven’t seen. Use MTTR to evaluate the whole response system and to spot trends after process changes, such as adopting runbooks or adding automation. If MTTA is low but MTTR is high, your paging works and your bottleneck is diagnosis or remediation.

​
Worked example

A payment API starts throwing errors at 14:00. The monitor fires at 14:02, and the on-call engineer acknowledges the page at 14:06. She identifies a bad deploy, rolls it back, and the service is confirmed healthy at 14:50.
  • Time to acknowledge: 14:02 → 14:06 = 4 minutes (contributes to MTTA)
  • Time to resolve: 14:02 → 14:50 = 48 minutes (contributes to MTTR)
If the previous month’s incidents averaged 6 minutes to acknowledge and 70 minutes to resolve, this incident improves both averages. Notice that only 4 of the 48 minutes were acknowledgment — here, shaving MTTA further buys little, while faster rollback tooling would cut MTTR meaningfully.

​
How this works in Rootly

Rootly calculates MTTA and MTTR automatically from alert and incident timestamps, with a pre-built dashboard you can slice by team, service, and severity. See On-Call Metrics.