Skip to content

Incident response time: how to measure and cut it

Incident response time shows how quickly the team detects an event, acknowledges it, and starts working on it. Three components are usually distinguished: MTTD (time to detect — from the start of the incident to its detection), MTTA (time to acknowledge — from detection to acknowledgment by the on-call engineer), and TTE/Time to Engage (until the right team is engaged). A short response time reduces downtime and the likelihood of breaching SLO/SLA.

What the metric measures

How fast you move from an event to actively working on resolving it, broken down by priority (P0–P3), service, region, and alerting channel (PagerDuty/Slack/phone). Separately track automated alerts vs manual reports, business hours vs after hours, and on-call shifts.

Calculation

  • MTTD = avg(DetectedAt − IncidentStart)
  • MTTA = avg(AcknowledgedAt − DetectedAt)
  • TTE (Engage) = avg(EngagedAt − DetectedAt) or until the required role joins (DB/SRE/App)
  • Response SLA, % = Incidents with MTTA ≤ target / Relevant incidents × 100
  • Calculate P50/P90 separately for stability and compare “on-hours” vs “off-hours”

Define when the clock starts and stops, time zones, business vs calendar hours, rules for merging related events, and escalation levels.

Calculation example

A failure occurred at 10:00, monitoring sent an alert at 10:04 and the on-call engineer started work at 10:12. Detection time is 4 minutes, response time 12 minutes from the start of the failure. The 15-minute target for critical incidents was met, but night-time incidents average 35 minutes.

Data sources

Monitoring/APM, alerting and on-call systems (PagerDuty/Opsgenie), ITSM incident logs (JSM/ServiceNow), communication channels (Slack/telephony), status page, on-call calendars.

Interpretation

  • MTTD↑ — insufficient SLI/synthetic monitoring coverage, “silent” alerting, thresholds not configured
  • MTTA↑ — problems with on-call schedules, escalations, mobile availability, or alert noise
  • TTE↑ — unclear runbooks, no automatic tagging of services/dependencies, weak triage
  • High values lead to MTTR↑ and error budget burn

Useful breakdowns

  • Priority (P0–P3); service/endpoint; region/zone
  • On-hours vs off-hours; team/role (SRE/DB/Network/App)
  • Alert type (automated/manual); source (APM/logs/synthetics)
  • Root cause (RCA): code/config/infrastructure/dependency/migration

Dashboard visualizations

  • Trend of P50/P90 MTTD/MTTA/TTE with target corridors
  • Response heatmap by service/hour/queue
  • Funnel “event → detected → acknowledged → engaged → restored”
  • Relationship with MTTR/Uptime and breach rate

How to set targets

Benchmarks for P0: MTTD ≤ 1–2 min, MTTA ≤ 5 min, TTE ≤ 10 min. Set up automatic escalations and multichannel alerts, reduce noise (alert hygiene), introduce runbooks and automated diagnostics, and keep on-call schedules and training up to date.

Common mistakes

  • No single source of event time; time zone confusion
  • Noisy/duplicate alerts without aggregation and correlation
  • No “after-hours” policy or compensation — slow response at night
  • Undefined escalation roles; manual triage without templates

Questions for discussion

  • Which alerts are most often ignored or acknowledged late, and why?
  • Where can MTTA be reduced through automatic escalations/on-call coverage?
  • Which runbooks are needed for faster TTE and consistent triage?
  • Are response targets aligned with the SLO/SLA for P0/P1?

Questions and answers

What is incident response time?

The time from an incident occurring (or being logged) to the responsible specialist starting work on it.

How do you calculate response time?

For each incident take the difference between occurrence or logging and start of work, then the average and the share within target by priority.

How do you shorten incident response time?

Set up monitoring and automatic alerts, organise on-call duty, define priorities and escalation, and train the team on typical scenarios.