Incident MTTx Metrics Calculator

{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}

Incident timestamps CSV:

Paste lifecycle rows or load one CSV/TXT file. ISO timestamps need UTC or an explicit offset.

{{ fileStatus || 'Drop one CSV or TXT file onto the textarea.' }}

{{ values.warning_rows.length }} data-quality note{{ values.warning_rows.length === 1 ? '' : 's' }}

{{ warning }}

Service or queue:

Use a service, team, queue, or review-window label. This value stays out of query state.

MTTA target:

Measured from detected/opened time to acknowledgement.

min

MTTC target:

Measured from detected/opened time to containment or mitigation.

min

MTTR target:

Measured from detected/opened time to recovery or resolution.

Tail percentile:

P85 is the neutral default and matches the established review brief.

Chart incident limit:

Eight rows is the neutral default. Every accepted row remains available in the ledger and exports.

Metric	Samples	Mean	Median	{{ tailLabel }}	Target	Status	Copy
{{ row.metric }}	{{ row.sample_count }}	{{ duration(row.mean_minutes) }}	{{ duration(row.median_minutes) }}	{{ duration(row.tail_minutes) }}	{{ row.target_minutes > 0 ? duration(row.target_minutes) : 'No target' }}	{{ row.status }}

Incident	Severity	MTTD	MTTA	MTTC	MTTR	Breaches	Next action	Copy
{{ row.id }}	{{ row.severity }}	{{ duration(row.mttd_minutes) }}	{{ duration(row.mtta_minutes) }}	{{ duration(row.mttc_minutes) }}	{{ duration(row.mttr_minutes) }}	{{ row.breaches.length ? row.breaches.join(', ') : 'None' }}	{{ row.next_action }}

Severity	Incidents	Average MTTR	Breached	Review focus	Copy
{{ row.severity }}	{{ row.incident_count }}	{{ duration(row.average_mttr_minutes) }}	{{ row.breached_count }}	{{ row.focus }}

An incident timeline contains several different delays, and compressing them all into “time to recovery” hides where response work actually slowed. Detection may lag behind customer impact, ownership may stall before acknowledgement, containment may take longer than expected, or the final recovery and validation work may dominate the event.

MTTx is a family name for mean-time measures. Four spans keep the delays separate: mean time to detect (MTTD), mean time to acknowledge (MTTA), mean time to contain (MTTC), and mean time to resolve (MTTR). MTTA, MTTC, and MTTR share the detected or opened timestamp as their response baseline. When that timestamp is absent, the incident start becomes the fallback baseline.

Started: Customer impact or incident onset, used as the beginning of MTTD and as a fallback response baseline.
Detected: The alert, report, or opened time that normally starts MTTA, MTTC, and MTTR.
Acknowledged: The point at which a responder or owning team accepts the incident.
Contained: The time impact is mitigated, stabilized, or prevented from spreading.
Resolved: The recovery or closure milestone used as the end of MTTR.

Incident timeline from started to detected, acknowledged, contained, and resolved with MTTD, MTTA, MTTC, and MTTR spans — MTTx spans are calculated from consistent incident lifecycle timestamps.

Means are familiar, but operational incident data often has a long tail. A few slow incidents can pull a mean upward, while many short incidents can make the mean look healthy even when the slowest cases repeatedly miss expectations. A selectable percentile adds that upper-tail view. P85, for example, is the smallest observed duration at or above the nearest-rank position for 85% of the sorted sample.

These metrics support review, not blame. Severity, staffing hours, dependency ownership, rollback risk, customer communication, and the team's timestamp policy all affect elapsed time. Trends are meaningful only when the incident population and milestone definitions stay consistent.

How to Use This Tool:

Prepare one CSV row per incident with consistent lifecycle milestones, then choose targets that match the service or review window.

Paste CSV text into Incident timestamps CSV or load a CSV/TXT file. A header is recommended; accepted concepts include incident ID, started, detected, acknowledged, contained, resolved, and severity.
Use ISO timestamps with Z or an explicit UTC offset. Date-only values are treated as midnight UTC. Review the data-quality warning for invalid, ambiguous, reversed, or missing timestamp pairs.
Give the population a Service or queue label, then set MTTA and MTTC targets in minutes and MTTR in hours. A target of zero disables breach checking for that metric.
Select a tail percentile from P75 through P99. Keep the same percentile when comparing review periods.
Compare mean, median, percentile, sample count, and target in MTTx brief. Then use Incident ledger and Severity breach queue to find the rows behind a missed target.
Check Stage latency profile for the longest resolved incidents, but remember that the chart limit changes only the displayed subset; accepted rows remain in the ledgers.

Interpreting Results:

A mean and selected percentile can disagree without either being wrong. When the mean meets target but P85 exceeds it, most incidents may be fast while the slower tail still needs attention. Sample counts matter because missing milestones are excluded per metric, so MTTD and MTTR can be based on different numbers of incidents.

A duration equal to its active target passes. Only a duration strictly greater than the target is marked as a breach.
MTTD has no configurable breach target; it is calculated whenever both started and detected timestamps form a valid non-negative pair.
Breached counts incidents that miss at least one active MTTA, MTTC, or MTTR target, not the total number of metric breaches.
The slowest-stage recommendation is a review prompt. Read the underlying incidents before changing alerts, paging, runbooks, or closure criteria.

Technical Details:

Each usable CSV row is parsed independently. Detected time is the preferred response baseline; started time is used only when detection is missing. Negative timestamp differences are excluded rather than forced to zero. A row remains useful when at least one metric can be calculated, so every metric reports its own sample count.

Formula Core:

Durations are elapsed minutes between timestamp pairs. The arithmetic mean and nearest-rank percentile are calculated from the valid values for each metric.

\begin{array}{l} MTTD = t_{detected} - t_{started} \\ MTTA = t_{acknowledged} - t_{base} \\ MTTC = t_{contained} - t_{base} \\ MTTR = t_{resolved} - t_{base} \\ \bar{x} = \frac{\sum_{i = 1}^{n} x_{i}}{n} \end{array}

The baseline is detected time when present, otherwise started time. The nearest-rank position is the ceiling of percentile divided by 100 times sample count; the one-based result selects that item from the sorted durations. Median uses the same rule at P50.

Transformation Core:

Incident CSV transformation stages
Stage	Rule
CSV recognition	Quoted commas and doubled quotes are supported. Header aliases accept common names such as incident, opened, acked, mitigated, recovered, and priority.
Timestamp validation	ISO date-time values require Z or an explicit offset. A bare date is normalized to midnight UTC. Invalid or reversed pairs produce warnings.
Row acceptance	Rows with fewer than four cells are skipped. A row also needs a valid detected timestamp or started fallback.
Metric population	Each metric keeps only its finite non-negative duration, so sample counts may differ.
Breach test	MTTA, MTTC, or MTTR is a breach only when duration > active target. Zero disables that target.

Stage-latency bars decompose MTTR into detection, acknowledgement, containment after acknowledgement, and recovery after containment. Negative residual stages are floored at zero. The focus recommendation chooses the positive stage with the largest mean, so missing milestones and fallback baselines should be reviewed before interpreting it as causal evidence.

Input is limited to 1 MiB and 1,000 data rows. The service label is limited to 80 characters. MTTA and MTTC targets accept 0 through 43,200 minutes, MTTR accepts 0 through 720 hours, the percentile accepts whole numbers from 50 through 99, and the chart accepts 3 through 12 incidents.

Privacy Notes:

CSV text and selected files are processed in the browser; there is no server-side incident calculation. The incident population and service label are not placed in shared query state. Treat copied or downloaded reports as operational data because they can contain incident identifiers, severities, durations, and review guidance.

Remove customer data, secrets, internal hostnames, and sensitive notes before pasting incident rows.
Use opaque incident IDs when a report will leave the response team.
Apply your organization's retention and access controls to any exported evidence.

Worked Examples:

One complete lifecycle

An incident starts at 00:00, is detected at 00:10, acknowledged at 00:20, contained at 01:10, and resolved at 03:10. The row contributes 10 minutes to MTTD, 10 minutes to MTTA, 60 minutes to MTTC, and 180 minutes to MTTR. Against targets of 15 minutes, 120 minutes, and 4 hours, it has no breach. With one row, mean, median, and P85 are identical; a tail percentile becomes more informative only after the population grows.

References:

Incident Metrics in SRE, Google Site Reliability Engineering.
How to choose incident management KPIs and metrics, Atlassian.
MTTA and MTTR reports, Splunk Documentation, July 16, 2025.