You have been asked to report on incident response, or you want to know whether on-call is working. MTTA and MTTR are the two numbers most teams start with. This post defines both, gives the formulas with worked examples, shows where MTTD fits, and lists what moves each number.
What does MTTA mean?
MTTA stands for mean time to acknowledge, the average time between an alert firing and a person acknowledging it. Acknowledging means a person says they have the incident. This action stops the escalation chain. It does not mean the problem is fixed.
MTTA measures the on-call process. It reflects how well routing, notification, and escalation move an alert to a single owner. If alerts go to a shared channel where everyone assumes someone else has it, MTTA stays high.
Some contracts and internal targets set a maximum time to acknowledge per priority level. That is a target for each individual incident. MTTA is the average you measure afterwards across many incidents.
The guide to building an on-call schedule covers how to give every alert a named owner.
How to calculate MTTA
MTTA = total time from alert to acknowledgement / number of incidents.
Consider three incidents acknowledged after 2, 4 and 9 minutes. The total time is 15 minutes. Divided by 3 incidents, the MTTA is 5 minutes.
You need the time each incident opened and the time it was acknowledged. Most on-call tools record both. If you track incidents in a spreadsheet, log the open and acknowledge times for each event.
What does MTTR mean?
MTTR is ambiguous because the R stands for one of four words.
| Term | Clock starts | Clock stops |
|---|---|---|
| Mean time to respond | The alert fires | Someone starts working on it |
| Mean time to repair | Work on the fix starts | The fix is in place |
| Mean time to recover (or restore) | The failure starts | The service works again for users |
| Mean time to resolve | The failure starts | The incident is closed, including follow-up work that stops it recurring |
Always write down which one you mean, and when the clock starts and stops. Two teams with the same incidents can report different numbers only because they define it differently.
MTTR formula
MTTR equals the total time across incidents divided by the number of incidents. Use whichever variant of MTTR you defined in the previous section.
Four incidents took 30, 45, 20 and 85 minutes from start to resolved. The total is 180 minutes. Divide 180 by 4 incidents. The MTTR is 45 minutes.
The same sum works for any variant, as long as the definition stays the same. If you switch from "time to recover" to "time to resolve" mid-quarter, the numbers before and after cannot be compared.
MTTA vs MTTR: what is the difference?
MTTA measures how fast a person takes ownership of an alert. MTTR measures how long until the problem is over.
MTTA is about the on-call process. It tracks routing, notification, and escalation. If MTTA is high, alerts are not reaching an owner.
MTTR depends on more than the on-call rotation. It also depends on diagnosis, runbooks, deploys, and the system itself. A low MTTA with a high MTTR means people respond fast but struggle to fix the issue.
MTTA is a part of MTTR when MTTR counts from the alert or the failure.
With a low MTTA and a high MTTR, look at runbooks and rollback. With a high MTTA, look at escalation policies and whether every alert has one owner.
What is MTTA, MTTR and MTTD?
MTTD stands for mean time to detect. It measures the time from when a failure starts to when monitoring raises an alert. This metric tracks your monitoring system, not the people on call.
The incident timeline runs in this order:
- The failure starts.
- The alert fires. MTTD ends here.
- A person acknowledges the incident. MTTA ends here.
- The service works again for users. Time to recover ends here.
- The incident is closed, including follow-up work. Time to resolve ends here.
Some teams also use MTTI, or mean time to identify, for the time spent finding the cause.
What the averages hide
A mean hides outliers. One incident acknowledged after 3 hours at night disappears in a month of 2-minute daytime acknowledgements. The average looks healthy while night alerts wait.
Look at the median and the slowest incidents. Split the data by priority and by working hours versus out of hours. The split shows where the process breaks.
Few incidents means a noisy number. With 5 incidents a month, one bad night moves the mean a lot.
There is no industry benchmark you can trust. Set a target per priority level from your own history. The post on incident priority levels covers how to define the levels.
How to improve MTTA
Five changes to the on-call process lower MTTA.
One owner per alert. Route each alert source to an escalation policy with a named roster. A shared channel where everyone assumes someone else has it creates gaps.
Escalate when nobody acknowledges. Set a second level after a fixed wait. An unanswered alert reaches another person instead of sitting in a queue.
Cut noise. Alerts that need no action train people to ignore alerts. Remove or downgrade them. Deduplicate repeats into one incident so one problem is one notification.
Notify the person who is awake. For teams in several timezones, a follow-the-sun rota sends the alert to the shift that is at work. The on-call schedule guide has a follow-the-sun example.
Make acknowledging mean something. Acknowledge means "I own it now", and it stops the escalation chain. Agree that as a team, so nobody acknowledges from habit and walks away.
Track MTTA together with time to resolve. People judged on MTTA alone learn to acknowledge fast, and the number stops telling you anything.
How to improve MTTR
MTTR depends on the system and on how people work an incident.
Link runbooks to alerts. Engineers should find the steps to fix the issue immediately.
Write clear alerts. An alert must say what is broken and where. A vague message leaves the responder guessing.
Enable fast rollback. If a deploy causes the failure, revert it quickly.
Add responders early. Bring in more people as soon as the problem is unclear.
Run post-incident reviews. Fix the cause so the incident does not recur.
Measuring MTTA and MTTR with OnCallAlerting
OnCallAlerting does not compute or report MTTA or MTTR. It records the timestamps you need to calculate them yourself.
Every incident has an activity timeline. It records when the incident was triggered, who was notified at each escalation level, and when it was acknowledged and resolved. Signed outbound webhooks send the same moments to your own systems: OnCallAlerting sends incident.triggered, incident.acknowledged and incident.resolved events, each with an occurred_at timestamp. You can feed these into your own spreadsheet or data store to compute both numbers.
Escalation policies are the feature that acts on MTTA: they notify an owner and move to the next level if nobody acknowledges. See the outbound webhooks docs and the escalation policies docs.
To try it, start a 30-day trial.