Paste one incident per line — when it started, when someone acknowledged it, when it was resolved — and get MTTA, MTTR, MTBF and the availability those incidents add up to.
Dates as YYYY-MM-DD HH:MM or ISO 8601. The acknowledged column is optional: with two values a line is read as started, resolved.
Runs entirely in your browser — nothing you enter here is sent to a server.
These three averages describe how often things break and how quickly you deal with it. MTTA (mean time to acknowledge) is how long an alert waits before a human picks it up. MTTR (mean time to resolve) is the full length of an incident, from the start of the impact to the fix. MTBF (mean time between failures) is the average quiet stretch between one incident ending and the next beginning.
Together they give availability: MTBF / (MTBF + MTTR). That formula makes the trade-off visible — you can reach the same availability by failing less often or by recovering faster, and recovering faster is usually the cheaper of the two.
From failure to alert. Invisible in most incident trackers, because the clock starts when the ticket is opened. External monitoring is what shortens it.
From alert to a person responding. Depends on routing, escalation and whether the alert was believable.
Finding the cause and applying a fix. Runbooks, dashboards and easy rollbacks matter most here.
Confirming the service is healthy again. An incident is not resolved until checks pass from the outside.
Means are sensitive to outliers: one six-hour incident among nine short ones dominates MTTR. That is why the median is shown next to it — if the two are far apart, look at the long incidents individually instead of the average. And with fewer than a dozen incidents, treat any trend as a hint rather than a measurement.
Add up the time from start to resolution for every incident in the period and divide by the number of incidents. Five incidents totalling 250 minutes give an MTTR of 50 minutes.
It varies: resolve, repair, recover or respond. This calculator uses "resolve" — the full time from the start of an incident until service is restored. Say which one you mean when you report the figure.
It depends on the service and its SLO. A useful test: multiply MTTR by the number of incidents you expect per month and compare the result with your downtime allowance.
Shorten detection with external monitoring, route alerts to someone who can act, keep runbooks for known failures and make rollback a one-step operation. Detection and diagnosis are normally the biggest parts.
Upzilla detects outages within a minute and alerts the right person, so the clock starts with you already on it. 10 monitors free.