Mastering the Calculation of MTTR for SRE

DocuWriter.ai helps engineering teams keep runbooks, API docs, architecture references, and code context current so responders spend less time hunting for answers during an incident. If your team is trying to improve the calculation of MTTR, start by making your operational knowledge as searchable and reliable as your telemetry. For a related workflow problem, see this guide on how to improve developer productivity.

A lot of teams think they have MTTR under control because they can quote a number from a dashboard. Then a real incident review happens, someone asks when the repair clock started, and the room gets quiet. One engineer counted the alert time. Another used the ticket creation time. The incident commander used the moment the rollback started. Finance pulled a downtime figure from a status report. None of those are automatically wrong, but mixing them makes the metric useless.

The practical problem isn’t the formula. The practical problem is timestamp integrity.

Introduction: Beyond the Outage Firefight

At 3 AM, the alert fires, someone opens logs, another person joins the incident channel, and a third person starts comparing the current deploy against the previous one. The service comes back, everyone goes back to bed, and the next day a simple question lands in the review: how long did that repair take?

That question sounds easy until you try to answer it from production data. Monitoring tools know when they fired. Ticketing systems know when someone created or closed an incident. Deploy systems know when rollback began. Logs know when errors stopped. None of those systems, by themselves, know exactly how long the team spent in the repair phase unless you’ve defined that phase clearly and captured it consistently.

A lot of published material stops at the basic formula and leaves out the implementation work. That’s why teams keep shipping unreliable MTTR numbers into dashboards and executive reports. A 2025 DevOps report highlighted that 65% of engineering teams miscalculate MTTR by including non-repair downtime from detection and validation phases, which can inflate metrics by 30-50% and lead to flawed SLO benchmarks (NexGen).

The useful version of MTTR starts with operational discipline. You need a stable incident lifecycle, consistent event names, synchronized clocks, and a rule for what counts as “repair” versus “detection,” “acknowledgment,” “recovery,” or “resolution.” Once that foundation exists, the math becomes simple and trustworthy.

What actually matters in day-to-day operations

The value of the calculation of MTTR isn’t academic. It shows whether your team is getting faster at restoring service, whether automation is working, and whether your runbooks help or slow people down. It also exposes an uncomfortable truth. Some teams don’t have a repair problem. They have a data collection problem disguised as a repair problem.

Three things usually separate useful MTTR programs from noisy ones:

• Stable definitions: Everyone uses the same start and stop points.
• Machine-collected timestamps: People don’t reconstruct timelines from memory.
• Post-incident cleanup: Teams reconcile missing or conflicting events while the incident is still fresh.

The shift from firefighting to measurement

Strong SRE teams don’t just close incidents. They create data that survives scrutiny. That means every incident should leave behind a timeline that another engineer can replay without asking the original responders what happened.

If you’re building this from scratch, don’t start with a giant executive dashboard. Start with one service, one incident schema, and one rule for how you’ll measure repair time. Clean data beats ambitious reporting every time.

MTTR and the Family of ‘Mean Time’ Reliability Metrics

Most confusion around MTTR comes from the fact that engineers use the same acronym to mean different things. In software operations, that ambiguity creates bad comparisons. One team reports hands-on fix time. Another reports full recovery from alert to service restoration. Both call it MTTR.

That difference matters because the number changes depending on where you start and stop the clock. Within modern incident management, variants like MTTR (Repair) and MTTR (Resolve) are used for different purposes. For example, six incidents with 240 minutes of active repair time yield an MTTR (Repair) of 40 minutes, but if root cause analysis adds another 180 minutes, the MTTR (Resolve) becomes 3 hours (Atlassian incident metrics).

Think like a pit crew

A Formula 1 pit stop is a good mental model. The car has a problem. Someone notices it. The crew gets ready. The car enters the pit. The crew performs the repair. The car leaves the pit. If you blur those steps together, you can’t tell whether your bottleneck is detection, handoff, or the repair itself.

In production systems, the same logic applies:

• MTTD asks how long the issue existed before someone or something detected it.
• MTTA asks how long it took for the responsible team to acknowledge it.
• MTTR Repair asks how long the hands-on repair work took.
• MTTR Recovery or Respond often includes more of the end-to-end restoration path.
• MTBF looks at the gap between failures, which is a reliability question rather than a response-speed question.

Reliability metrics compared

That table is why reliability reviews shouldn’t ask for “the MTTR” without context. Ask which MTTR. If you’re not explicit, the metric turns into a naming argument instead of an operational tool.

Why developers should care

Developers often assume these are ops-only metrics. They aren’t. If the deploy pipeline causes repeated rollback incidents, if ownership is fuzzy, or if nobody can find the right service diagram during an outage, application teams directly shape these numbers.

Teams that already use delivery metrics will recognize the overlap. DORA work made this especially visible because recovery speed sits next to change-oriented metrics in the same performance conversation. If you want a broader view of engineering measurement beyond incident data, Wonderment Apps’ guide on agile performance is a useful companion read. For a software delivery lens, DocuWriter.ai also has a practical breakdown of software development KPI.

Sourcing and Cleaning Data for Accurate Calculation

The most painful part of the calculation of MTTR is rarely the arithmetic. It’s extracting clean event times from systems that were never designed to agree with each other. Monitoring, ticketing, chat, deployment pipelines, and logs all record part of the incident, but not the same part.

For software teams, the cleanest approach is to define a canonical incident record and then map every tool into it. At minimum, that record needs an incident identifier, service name, severity, and explicit lifecycle timestamps. Without that normalization layer, teams end up calculating against whatever export was easiest to grab that week.

The timestamp sources that usually matter

Many teams already have enough raw material. They just haven’t aligned it.

• Monitoring and alerting systems: Use these for detected time, alert trigger time, and sometimes resolution signals when alerts auto-close.
• Incident management platforms: Use these for acknowledgment, assignment, escalation, and declared resolution times.
• Application and infrastructure logs: Use these to validate symptom start, mitigation start, and error-rate recovery.
• Deployment tools: These can prove when rollback, config revert, or hotfix deployment started.
• ChatOps timelines: These help reconstruct human actions, but they shouldn’t be your primary source unless you’re forced into manual reconstruction.

A practical canonical schema

Keep the schema boring. Boring schemas survive handoffs.

The cleaning work teams underestimate

Raw data arrives messy. Time zones differ. Some tools emit ISO timestamps, others export local time strings. One incident may have duplicate alerts and another may never be formally resolved in the ticketing tool even though the service recovered.

A simple cleanup process helps:

1. Normalize all timestamps to one standard, usually UTC.
2. Deduplicate incident records where the same outage generated multiple alerts or tickets.
3. Reject or flag impossible timelines, such as resolved times before detected times.
4. Separate automated recovery from manual repair, especially in autoscaling or self-healing environments.
5. Preserve provenance, so you know whether a timestamp came from monitoring, logs, or a human update.

For teams doing first-pass cleanup outside a data platform, lightweight spreadsheet discipline still helps. A practical reference for structuring messy operational exports is this guide to data preprocessing in Excel.

The measurement boundary that makes or breaks the metric

Teams often diverge in their methodologies. Some use alert-to-fix. Others use wrench time only. Others include validation, RCA, and ticket closure. None of those are universally right. What matters is consistency and naming.

For pure Mean Time to Repair, keep the focus on the active repair phase. If you also care about overall service recovery, track that separately. Mixing both into one number creates false comparisons and bad incentives.

Applying the Core MTTR Formula with Numeric Examples

At 03:17, PagerDuty fires. By 03:41, customer errors are back to baseline. The formula is the easy part. The harder part is deciding which two timestamps belong in the calculation and making sure every incident row follows the same rule.

The canonical formula

Use this in dashboards, runbooks, and post-incident reviews:

MTTR = Total Repair Time / Number of Repairs

Simple math. Strict inputs.

If the team measures one incident from repair_started_at to service_restored_at, but another from alert_fired_at to ticket_closed_at, the average stops being operationally useful. It becomes a mix of response time, repair time, validation time, and admin lag.

Example one with hours

Assume a monthly incident export contains three valid repair durations:

• Incident 1: 3 hours
• Incident 2: 1.5 hours
• Incident 3: 4.5 hours

Add the repair time:

3 + 1.5 + 4.5 = 9 hours

Count the incidents:

3

Calculate MTTR:

9 / 3 = 3 hours

So the MTTR is 3 hours.

This is the clean textbook case. Real systems only produce a number this clean after someone has already reconciled monitoring events, ticket state changes, and log-derived recovery markers.

Example two with minutes

Minutes are usually a better unit for software services. They expose regressions that disappear when everything is rounded to hours.

Suppose six incidents consumed 240 minutes of active repair time in total. The calculation is:

240 / 6 = 40 minutes

Here’s the same math in code:

total_repair_minutes = 240
incident_count = 6

mttr = total_repair_minutes / incident_count
print(f"MTTR: {mttr} minutes")

Output:

MTTR: 40.0 minutes

If your team needs help turning incident exports into production-grade calculations, experienced python developers can wire together ticket APIs, log pipelines, and reporting jobs. For the documentation, code understanding, and system context around that pipeline, DocuWriter.ai is the stronger long-term choice.

Example three with real timestamp fields

This is the version teams implement.

Assume you collect two normalized fields per incident:

• repair_started_at
• service_restored_at

And your cleaned incident table looks like this:

Total repair time:

25 + 40 + 15 + 20 = 100 minutes

Incident count:

4

MTTR:

100 / 4 = 25 minutes

That result is only credible if the table is audit-friendly. Each row should be traceable back to source events. In practice, that means a monitor opened the incident, logs or deployment markers showed when mitigation started, and an SLI or health check confirmed restoration.

The trade-off that changes the number

Teams often calculate one of two related metrics:

1. Active repair MTTR. Time from repair start to service restoration.
2. Response-to-restore MTTR. Time from initial detection or alert to service restoration.

Both are useful. They answer different questions.

If an incident was detected at 09:00, repair work started at 09:12, and service was restored at 09:42, then:

• Active repair time = 30 minutes
• Response-to-restore time = 42 minutes

A team optimizing on-call triage, escalation paths, and alert routing should care about the second number. A team trying to reduce hands-on remediation effort should watch the first. Put both in the data model if possible. Label them clearly. Do not collapse them into one field called mttr_minutes.

A practical audit rule

Before publishing MTTR, spot check five rows by hand.

For each one, verify:

• the incident count is correct
• the start timestamp matches the agreed event boundary
• the restore timestamp reflects actual service recovery, not ticket closure
• the duration is positive and in the expected unit

This catches a surprising amount of bad data. One stale ticket workflow or one timezone parsing bug can shift the monthly average enough to trigger the wrong engineering discussion.

What to include and exclude

Document the rule set in plain language:

• Include unplanned repair work such as outages, failed deploy rollback, and emergency config fixes.
• Exclude planned maintenance and routine service requests.
• Use one unit per dataset, usually minutes for digital services.
• Keep the sample window fixed, such as calendar month or quarter.
• Exclude records with missing or invalid endpoints unless your process defines a backfill rule.

The formula is stable. The incident table is where MTTR gets won or lost.

DocuWriter.ai helps teams keep those definitions, field mappings, and calculation rules aligned across code, queries, and operational docs, which is what keeps an MTTR dashboard trustworthy after the first version ships.

Automating MTTR Calculation with SQL, Python, and PromQL

Manual calculations help during incident reviews, but they don’t scale. Once the team agrees on event boundaries, automate the pipeline so every report uses the same rules. The core pattern is always the same: filter incidents in a defined window, compute repair duration for each valid record, sum those durations, and divide by the number of incidents.

SQL example for incident tables

Assume you have a table called incidents with repair_started_at and service_restored_at.

SELECT
  COUNT(*) AS incident_count,
  SUM(EXTRACT(EPOCH FROM (service_restored_at - repair_started_at)) / 60.0) AS total_repair_minutes,
  SUM(EXTRACT(EPOCH FROM (service_restored_at - repair_started_at)) / 60.0) / COUNT(*) AS mttr_minutes
FROM incidents
WHERE repair_started_at IS NOT NULL
  AND service_restored_at IS NOT NULL
  AND incident_type = 'unplanned'
  AND service_restored_at >= DATE_TRUNC('month', CURRENT_DATE)
  AND service_restored_at < DATE_TRUNC('month', CURRENT_DATE) + INTERVAL '1 month';

This query does three useful things. It excludes records with missing endpoints, filters out planned work, and calculates the metric in minutes. That’s usually enough for a dashboard card and a monthly review.

If your team stores lifecycle timestamps in a warehouse, add dimensions such as service, severity, and team so you can group and compare:

SELECT
  service,
  COUNT(*) AS incident_count,
  SUM(EXTRACT(EPOCH FROM (service_restored_at - repair_started_at)) / 60.0) / COUNT(*) AS mttr_minutes
FROM incidents
WHERE repair_started_at IS NOT NULL
  AND service_restored_at IS NOT NULL
  AND incident_type = 'unplanned'
GROUP BY service
ORDER BY mttr_minutes DESC;

Python example with pandas

For teams working from CSV exports or notebooks, pandas is often the fastest path.

import pandas as pd

df = pd.read_csv("incidents.csv")

df["repair_started_at"] = pd.to_datetime(df["repair_started_at"], utc=True)
df["service_restored_at"] = pd.to_datetime(df["service_restored_at"], utc=True)

valid = df[
    df["repair_started_at"].notna() &
    df["service_restored_at"].notna() &
    (df["incident_type"] == "unplanned")
].copy()

valid["repair_minutes"] = (
    valid["service_restored_at"] - valid["repair_started_at"]
).dt.total_seconds() / 60

mttr_minutes = valid["repair_minutes"].sum() / len(valid)

print(f"Incident count: {len(valid)}")
print(f"Total repair minutes: {valid['repair_minutes'].sum()}")
print(f"MTTR minutes: {mttr_minutes}")

That script is intentionally simple. It gives you an auditable column for each incident duration before computing the mean. That makes validation much easier during a review.

If you’re staffing this kind of workflow and want to see how organizations think about specialized Python talent, this overview for python developers provides useful context.

PromQL example for alert-based recovery measurement

Prometheus isn’t an incident management system, so use PromQL carefully. It’s better for service recovery timing than for full incident lifecycle accounting. If you emit a counter or summary from your incident pipeline, PromQL can aggregate it cleanly.

For example, if your system records repair duration in minutes as a metric per resolved incident:

sum(increase(incident_repair_minutes_sum[30d]))
/
sum(increase(incident_repair_minutes_count[30d]))

This pattern works well when your application or incident collector exports a summary-style metric. The numerator gives total repair minutes over the window. The denominator gives the number of repaired incidents over the same window.

What works and what doesn’t

Good automation patterns:

• Push normalized incident records into one store before calculating MTTR.
• Keep the formula visible in code and dashboards so engineers know what they’re seeing.
• Version your metric definition when the team changes start or stop rules.

Weak patterns:

• Computing MTTR directly from raw alert timestamps without incident correlation.
• Letting each team export from its own system and average the results later.
• Relying on ticket close time as service restoration time when those are operationally different events.

Interpreting MTTR for SRE, DevOps, and SLAs

At 03:17, the page fires, the dashboard turns red, and three systems disagree about what “resolved” means. Monitoring says recovery happened at 03:29. The incident ticket was closed at 04:12. The change record for the rollback landed at 03:24. That gap is why MTTR needs interpretation, not just calculation.

For SRE and DevOps teams, MTTR is useful only if it changes engineering work. A single average can hide whether delays happen in detection, triage, mitigation, handoff, or verification. The number starts to matter when it is tied to service boundaries, severity, and a clear timestamp policy that survives contact with real incident data.

Read MTTR through data quality and service impact

I treat MTTR as an operational signal, not a score for leadership slides. If the underlying timestamps are messy, a clean-looking average still points the team in the wrong direction. A low MTTR can reflect aggressive ticket closure or weak severity rules instead of fast recovery.

What deserves attention:

• Trend over time: Are repairs getting faster after runbook, alert, or rollout changes?
• Spread, not just average: Are a few long incidents dominating the month?
• Service-level segmentation: Which systems have the longest restore path after user impact starts?
• Severity segmentation: Do Sev 1 incidents recover within the window your team promised?
• Timestamp source consistency: Are start and restore times coming from the same incident lifecycle definition?

A practical example helps. Service A shows a 22-minute MTTR for the quarter. That sounds healthy until the team breaks it down and finds a pattern: database failovers usually recover in under 10 minutes, but dependency timeouts in the checkout path often stay open for 45 minutes because ownership bounces between platform and application teams. The average is acceptable. The workflow is not.

Useful dashboard views

A good MTTR dashboard should help an on-call engineer and an engineering manager answer different questions from the same dataset.

Include the raw fields behind the chart. I want to click an incident and see detected_at, acknowledged_at, mitigated_at, service_restored_at, and ticket_closed_at. Without that drill-down, teams argue about the metric instead of fixing the response path.

MTTR in SLO and SLA discussions

MTTR belongs in the same conversation as SLOs because recovery time controls how long users sit inside the error budget burn. Two services can have the same incident count and very different user impact if one recovers in 8 minutes and the other in 50.

For SLAs, the interpretation has to be stricter. Customer-facing commitments care about restoration windows, not internal cleanup work. If your SLA says service must be restored within 30 minutes, using ticket closure time will overstate breach risk. If your metric uses mitigation time while the SLA uses full service restoration, you will understate it. Teams need both definitions, labeled clearly, with no mixing on the same dashboard.

This also connects to broader delivery reporting. Teams that track MTTR alongside deploy frequency, change failure rate, and other agile engineering KPIs get a clearer view of whether faster delivery is creating longer recovery work.

Questions worth asking when MTTR rises

Start with the workflow, not the people.

1. Did alert correlation fail and create multiple starts for one customer-visible incident?
2. Did responders lose time reconciling timestamps across logs, tickets, and monitoring tools?
3. Did the team restore service quickly but delay marking the incident as restored?
4. Did ownership or escalation add latency between diagnosis and action?
5. Did one class of incident regress after a deployment, infrastructure change, or dependency update?

Those questions push the discussion toward repairable system issues. Better runbooks, cleaner event normalization, and clearer restore criteria usually improve MTTR more than asking engineers to “move faster.”

How to use the number responsibly

Compare MTTR only when the incident definitions and timestamp sources match. Set targets after you have a stable baseline with enough incident volume to be meaningful. Keep a separate view for restored service versus fully resolved operational work.

DocuWriter.ai helps teams document those metric definitions, map code changes to incidents, and keep reliability knowledge current across services. Use it as the system of record for runbooks, incident conventions, and code intelligence so MTTR stays tied to real engineering behavior instead of spreadsheet folklore.

Common MTTR Calculation Mistakes to Avoid

Most bad MTTR numbers come from process shortcuts, not mathematical mistakes. Teams pull timestamps from whatever tool is easiest, mix incident types, and average durations without checking whether the records describe the same lifecycle. The result looks precise and drives the wrong changes.

One of the hardest cases is parallel repair work in distributed systems. A frequently unaddressed issue is handling concurrent repairs in microservices, where multiple teams fix failures at the same time. Standard formulas assume sequential tasks, which can understate effective MTTR by 40% in scenarios where multiple outages are repaired in parallel over the same calendar period (TechTarget on reducing MTTR).

Mistake patterns that show up often

• Mixing planned and unplanned work: Scheduled maintenance doesn’t belong in MTTR. It makes the metric look worse without telling you anything about incident response.
• Using closure time as restoration time: Tickets often close well after users recovered.
• Combining different MTTR variants: Repair, recovery, and resolve are not interchangeable.
• Ignoring missing data: An average built on incomplete records can look stable while hiding major gaps.
• Treating parallel incidents as one linear workflow: This distorts repair effort in multi-team environments.

What to do instead

Mean versus median

The mean is standard and useful, but it can be skewed by a single ugly outage. In practice, many teams look at the mean for formal reporting and the median for operational sanity checks. If one incident lasted far longer because of a vendor dependency or a cross-team handoff, the median helps you see the usual case without pretending the outlier didn’t happen.

Define what “done” means

This is the quiet source of many arguments. Is the repair done when the rollback finishes, when error rates normalize, when a responder declares service healthy, or when the incident ticket is closed? Pick one rule per metric and document it in writing.

The strongest teams keep a checklist for every incident dataset:

• One incident type policy: only unplanned repairs
• One time boundary policy: documented start and stop events
• One source hierarchy: preferred systems for each timestamp
• One data review pass: reject broken records before computing the average
• One concurrency note: explain how overlapping work is treated

DocuWriter.ai is the practical place to tighten the documentation side of incident response. Teams use it to generate and maintain code documentation, API references, UML diagrams, and refactoring context so responders can find architecture details, ownership clues, and recovery steps faster. If you’re serious about improving the calculation of MTTR, pair clean timestamp pipelines with better operational documentation, and make DocuWriter.ai the system that keeps that knowledge current.