MTTR, MTTA and MTBF: what you are actually measuring

MTTR has four common meanings

The acronym is used for at least four different measurements that overlap but are not interchangeable[Atlassian]. Always name the one you mean.

Definitions vary between organizations and tools. Atlassian's description of mean time to resolve, for example, includes the work to prevent recurrence and notes it is often tracked in business hours[Atlassian]. Our calculator uses a narrower, explicit definition: from detected_at to resolved_at as your team recorded them. Whatever you pick, write it down.

MTTA: mean time to acknowledge

MTTA is the average time from an alert or detection to someone acknowledging it and starting work[Atlassian]. It reflects on-call responsiveness and, indirectly, alert fatigue: if people routinely ignore pages, MTTA rises.

Formula: sum of (acknowledged minus detected) for incidents that have both timestamps, divided by the number of those incidents. Incidents with no acknowledgment recorded should be excluded and counted as missing, never treated as zero, which would flatter the result.

MTBF: mean time between failures

MTBF is the average operating time between failures of a repairable system: total operational time divided by the number of failures[Atlassian]. It is easy to compute wrongly. Before reporting it, make sure all of these are true:

• One service. MTBF for "all our systems combined" does not describe the reliability of any of them.
• An explicit window. Choose start and end dates in advance. Do not infer the window from the first and last incident, which shrinks it artificially.
• Complete outage data. Every qualifying failure in the window must be in the dataset, with both start and restore times.
• Overlaps merged. Two incidents that overlap on the same service are one period of downtime, not two.
• Zero failures means undefined. With no failures, MTBF has no value. Report "N/A", not infinity or the window length.

Formula: (window duration minus merged downtime) divided by the number of failures that started inside the window.

Worked example (hypothetical data)

Three fictional incidents on one service, example-api, in a three-day window from 2026-10-01 00:00 to 2026-10-04 00:00 UTC. These are invented numbers for illustration. They are also the calculator's sample CSV, so you can reproduce every figure.

Resolve MTTR (60 minutes) and recover MTTR (about 50.7 minutes) differ by about nine minutes for the same three incidents. Blending them, or switching between them from one month to the next, would make the trend meaningless.

Choosing measurement boundaries

• Start: impact start (when users were first affected) or detection (when you knew). Impact start is more honest about user experience but often has to be reconstructed from logs.
• End: recovery (users can work again) or resolution (cleanup and permanent fix done). Recovery is what users feel; resolution is what the team spends.
• Inclusion: which incidents count. Exclude planned maintenance and service requests, and say so. Decide whether low-priority incidents are in or out.
• Consistency: once chosen, keep the same boundaries across periods. If you change them, restate earlier periods or mark a break in the series.

Mean vs median

Incident durations are usually skewed: most are short, a few are very long. The mean is pulled up by the long tail. Hypothetical example: four incidents lasting 10, 12, 15 and 240 minutes have a mean of 69.25 minutes and a median of 13.5 minutes. Neither is wrong, but they tell different stories. Report both, along with the count, and look at the long incidents individually.

Time zones, daylight saving and business hours

Record every timestamp with a timezone offset, for example 2026-03-08T01:30:00-05:00, or in UTC. Local times without an offset are ambiguous around daylight saving changes: on the night clocks fall back, 01:30 happens twice. With offsets, durations are computed between real instants and are always correct.

Wall-clock vs business hours. A hypothetical incident detected Friday at 16:30 and resolved Monday at 09:30 took 65 hours of wall-clock time, but only one hour of a 09:00 to 17:00 business day. Teams with round-the-clock coverage normally use wall-clock time; teams that only support business hours often use business time. Either is defensible, but label it, and never mix the two in one average.

Common reporting pitfalls

• Treating missing acknowledgments or resolutions as zero.
• Averaging across services with very different architectures and calling it reliability.
• Inferring the MTBF window from incident dates.
• Double counting downtime when incidents overlap.
• Rewarding low MTTR so heavily that teams close incidents early or stop declaring them.
• Comparing your number with someone else's without knowing their definitions.

About benchmarks

We do not publish "industry average MTTR" figures. Published numbers rarely state which MTTR they mean, which incidents they include, or how they were measured, so comparing your number to them can mislead. Compare your own periods instead, using consistent definitions. The calculator supports this with a second comparison window.