Mean Time to Resolution: Formula and Improvement Guide

Mean time to resolution (MTTR) is the arithmetic average time required to take incidents from a defined starting event to a defined resolution event. The formula is:

Mean time to resolution = total resolution time for incidents in scope ÷ number of resolved incidents in scope

The calculation is easy. The useful work is defining “start,” “resolution,” and the incident population consistently. If one record stops when service returns and another stops when a permanent fix ships, their durations should not be averaged as if they measure the same process.

MTTR is best used as a diagnostic summary alongside the full duration distribution, incident count, customer impact, and phase timings. It is not a universal reliability score or a target that can be compared safely across unrelated services.

What mean time to resolution measures

For incident management, mean time to resolution usually describes the average elapsed time between a qualifying incident start and the point at which the team's documented resolution condition is met. A practical policy might define those boundaries as:

• Start: the first valid automated detection or accepted user report that creates the incident record.
• Resolution: user-facing service is stable, recovery has been verified against explicit checks, and the incident owner marks the event resolved.

That definition is not mandatory. Consistency is. Publish the clock policy beside the number so another person can reproduce it from the source records.

For incident (i):

resolution_duration_i = resolved_at_i - started_at_i

MTTR = sum(resolution_duration_i) / count(resolved incidents)

Only include records that satisfy the same incident policy and have both valid timestamps. Open incidents do not have a final duration; silently omitting them can make the current period look better during a long outage, so report the open count and oldest open age separately.

Convert every duration to the same unit before summing it. If the cohort contains no resolved incidents, MTTR is undefined; report a resolved-incident count of zero rather than publishing 0 minutes.

Atlassian's incident-metrics guide highlights a central MTTR problem: the “R” may mean repair, recovery, respond, or resolve. Those clocks overlap, but they are not interchangeable.

These are example boundaries, not standards shared by every tool. Atlassian uses “mean time to respond” for alert-to-functional-service time and separately defines mean time to acknowledge (MTTA) as alert-to-work-begins time. Other organizations may use “respond” differently. Name the expansion and exact boundaries in dashboards and APIs rather than displaying an unexplained MTTR field.

Define every clock boundary

Keep distinct timestamps even if a small team initially reports only one MTTR:

Do not backfill all fields with the same convenient timestamp. Missing data should remain missing and be counted as a data-quality issue.

Recovery is not always resolution

A rollback may restore checkout while leaving a broken release, corrupted queue, or unsafe configuration to repair. Record at least two outcomes:

• User-visible recovery: when the service again meets its defined service-level condition.
• Permanent resolution: when the incident's documented corrective condition is complete.

If a long-term code change arrives days later, teams often close the operational incident after stable recovery and track the permanent fix as a separate owned action. That is valid when the policy says so. It is not valid to move the stop time opportunistically to make the metric smaller.

DORA's current software-delivery metric is narrower. The measure once called “time to restore service” is now failed deployment recovery time: recovery from an impairment caused by a production deployment. A database hardware failure, expired certificate, or provider outage can belong in an incident MTTR dataset but not in that DORA deployment metric. Report them separately.

Mean time to resolution formula with an example

Suppose four incidents use the same detected_at start and verified resolved_at stop:

The total is 180 minutes across four incidents:

MTTR = (16 + 24 + 40 + 100) / 4
MTTR = 180 / 4
MTTR = 45 minutes

The median is 32 minutes: the midpoint between 24 and 40. The single 100-minute incident pulls the mean above the duration of three out of four incidents. That is not a reason to discard the outlier. It is a reason to show the distribution and investigate what made that incident different.

Decompose one incident into phases

An end-to-end duration says that a response was slow, but not where time was lost. For an incident detected at 09:02 and resolved at 09:52, record the transitions:

The phases total 50 minutes. Service was restored at 09:39 and verified at 09:43, so detection-to-restoration is 37 minutes, detection-to-verified-recovery is 41 minutes, and detection-to-resolution is 50 minutes. If impact began at 08:58, the user-visible impact window through restoration is 41 minutes; the verification-inclusive window through 09:43 is 45 minutes. Each value answers a different question.

This decomposition also prevents a common mistake: treating fast mitigation as proof of fast response while acknowledgment or verification consumed most of the incident.

Why the mean is not enough

Production incidents are usually infrequent, mixed, and strongly skewed. A few long events can dominate an average, while a quiet month may contain too few incidents to support a stable trend. Google's Incident Metrics in SRE report demonstrates why mean time to recovery and mitigation can be poorly suited to trend analysis and decisions when incident samples behave this way.

Report MTTR with:

• incident count and number still open;
• median duration;
• p75 and p90 when the sample is large enough to make them meaningful;
• minimum, maximum, and preferably the underlying distribution;
• the measurement window and clock policy;
• data completeness and the percentile calculation method;
• customer-impact duration or affected-user measure where available.

For a small sample, showing the individual durations is more honest than publishing a precise-looking p90. For larger samples, percentiles answer practical questions: the median describes a typical incident, while p75 or p90 exposes the slower tail that an average can hide.

Segment before drawing conclusions

Compare incidents with similar response obligations and failure modes. Useful dimensions include:

• severity and customer impact;
• service or product area;
• incident class, such as deployment, dependency, capacity, security, or infrastructure;
• environment and region;
• detected automatically versus reported by a user;
• working hours versus on-call hours, if staffing differs.

Always show the segment sample size. A service with two severe incidents should not be ranked against a service with hundreds of low-impact support events. There is no universal “good MTTR”: architecture, traffic, risk, severity policy, and the chosen clock all change the value.

Do not turn MTTR into an individual performance score. It creates pressure to delay incident declaration, downgrade severity, or close records before recovery is proven. Measure the system and response process, not the person who was on call.

Build an auditable incident record

Use one system of record for incident lifecycle timestamps. Monitoring, deployment systems, chat, tickets, logs, and status pages can supply evidence, but the incident record should identify which source set each transition.

This compact example separates user impact, response phases, recovery, and closure:

{
  "incident_id": "INC-204",
  "service_name": "checkout-api",
  "environment": "production",
  "severity": "SEV-1",
  "incident_class": "deployment",
  "impact_started_at": "2026-09-15T08:58:00Z",
  "detected_at": "2026-09-15T09:02:00Z",
  "acknowledged_at": "2026-09-15T09:06:00Z",
  "diagnosis_confirmed_at": "2026-09-15T09:20:00Z",
  "mitigation_started_at": "2026-09-15T09:20:00Z",
  "service_restored_at": "2026-09-15T09:39:00Z",
  "recovery_verified_at": "2026-09-15T09:43:00Z",
  "resolved_at": "2026-09-15T09:52:00Z",
  "closed_at": "2026-09-15T10:18:00Z",
  "triggering_change_id": "deploy_8f21c",
  "reopened_count": 0
}

The values are illustrative. In production, store who or what asserted each transition, the original source event, and later corrections. Preserve the original timestamp when a field is amended rather than silently replacing history.

Handle data-quality edge cases explicitly

Time zones and clocks: Store timestamps in UTC with an offset and retain source timestamps. Synchronize system clocks. Record both event time and observed or received time when delayed ingestion is possible.

Elapsed versus business time: Reliability incidents should normally use continuous elapsed time. Support commitments may use business calendars. Never combine them in one mean; label both clock types.

Paused time and exclusions: Decide in advance whether any state pauses the clock. Waiting for a vendor, a maintenance window, or a handoff does not disappear from elapsed time unless the published policy explicitly excludes it. Store pause start, pause end, and reason instead of subtracting time manually during reporting.

Reopened incidents: Keep the original incident ID. Record first recovery, reopen time, final stable recovery, and final resolution. Choose whether the primary resolution clock stops only after stable recovery, then apply that policy to every record.

Partial recovery: Define a measurable recovery threshold from the service-level indicator or user journey. Do not stop the clock because some traffic recovered while a material cohort remained broken. When impact declines gradually, retain the impact levels rather than forcing one timestamp to describe the whole curve.

Overlapping incidents: Each incident can have its own response duration, but overlapping impact intervals cannot be added directly to claim total customer downtime. Use the union of impact intervals for service downtime and preserve links between parent, child, or duplicate incidents.

Closure delay: A delayed review meeting can inflate a clock that ends at closed_at without extending user impact. Track verified recovery, resolution, and administrative closure separately.

Missing or invalid order: Reject negative durations and flag impossible transitions. Report completeness instead of silently dropping bad rows.

Find the phase that needs improvement

Break the lifecycle into observable transitions before choosing a tool or process change.

Google's monitoring guidance separates alerting signals from diagnostic evidence. SLO dashboards can show that users are affected, while logs and debugging metrics help explain why. That distinction prevents teams from expecting one data source to detect, diagnose, and prove recovery equally well.

How to reduce mean time to resolution

The goal is not to pressure responders to work faster. Reduce waiting, ambiguity, unsafe choices, and repeated investigation.

Alert on customer impact

Start with service-level indicators tied to real user journeys. Page for conditions that require prompt human action, and route slower or lower-impact work to tickets. Google's SLO alerting guidance evaluates precision, recall, detection time, and reset time, and warns that low-traffic services need special treatment. Test alert delivery and escalation before an incident.

Make ownership immediate

Every production service should identify an owning team, current escalation path, critical dependencies, and the first safe checks. During a significant incident, assign incident command, operational, and communication responsibilities instead of letting everyone change the system simultaneously. Google's incident response model describes these roles and the value of a shared working record.

Put changes on the timeline

Record deployments, feature-flag changes, configuration updates, migrations, and dependency releases with service, environment, version, actor, and change ID. Google's troubleshooting guidance recommends correlating changes with system behavior and logging deployments and configuration changes. A marker is a clue, not proof of causation.

Keep runbooks executable and safe

A runbook should name the symptom, prerequisites, read-only checks, approval boundary, smallest mitigation, verification, and reversal path. Test high-risk recovery steps in an appropriate environment. Prefer a known rollback, traffic shift, feature disable, or capacity action over improvised production changes when evidence supports it.

Validate recovery where users experience it

The absence of a new error is not enough. Check the affected user journey, SLI, dependency health, backlog, and data correctness. Keep the incident open through a documented stability window when the failure can recur. Use the same recovery definition across the dataset.

Learn without changing the historical clock

Run blameless reviews for incidents that meet a published threshold. Focus on system conditions and response gaps, then assign concrete actions with owners and due dates. Google's postmortem guidance emphasizes reviewed postmortems and measurable, tracked action items. Do not rewrite incident timestamps after the review to make reporting cleaner.

Use logs to shorten diagnosis and verification

Logs are most useful when a responder can move from the incident ID or request ID to the affected service, environment, version, host or workload, and error without copying secrets between tools. Emit structured, stable fields before an incident:

• service_name, environment, region, and version;
• request, job, message, deployment, and incident IDs when they genuinely exist;
• severity and a stable event name or error type;
• dependency and retry context without credentials or payloads;
• timestamps with clear event-time semantics.

Do not invent a correlation ID after the fact or assume similarly timed events share a cause. A request ID joins one request path; an incident ID groups evidence selected under an incident policy. Preserve raw messages and source identifiers so a conclusion can be checked.

During response, start with the incident window and affected service. Add environment, version, host, severity, and stable message filters only as evidence narrows the question. Compare the first failing version with the last known-good version. After mitigation, use the same query and a user-facing check to look for recovery; a quiet log stream can also mean collection failed.

Fluxtail is a paid Starter and Pro logs-focused service. When collectors deliver and map the relevant fields, its search and filters can narrow retained logs by time, stream, message, service, severity, labels, and documented Kubernetes fields. Live Tail follows new logs and lets an operator inspect each stored row's message, timestamp, service fields, host, labels, and Kubernetes fields when present. Fluxtail does not provide application performance monitoring, tracing, or metrics; use those signals alongside logs where the investigation needs them.

Fluxtail's built-in AI chat is separate from its hosted MCP. Hosted MCP uses OAuth with PKCE, asks for account consent, and binds a connection to one account. Its read tools can query logs and diagnostics; operator mutations use a proposal and short-lived confirmation token. Use either investigation surface on a bounded stream and time window, confirm summaries against the stored rows, and keep incident-system timestamps as the MTTR source of record.

For a practical active-incident sequence, see live-tail incident response. For durable collection and retention design, use the log management best-practices guide.

Create a Fluxtail account when incident diagnosis needs retained, searchable logs beyond one host or terminal.

MTTR reporting checklist

Before publishing a mean time to resolution report, confirm:

• The “R” is written out and the start and stop events are documented.
• User-visible recovery, permanent resolution, and administrative closure are separate.
• Only comparable incident classes and severities are grouped.
• Open, reopened, overlapping, and partially recovered incidents follow a stated policy.
• Elapsed and business-hour clocks are not mixed.
• Timestamps use consistent time zones and retain their sources.
• Mean, median, tail percentiles where meaningful, sample size, and data completeness are shown.
• The raw distribution and longest incidents can be inspected.
• DORA failed deployment recovery time is reported only for deployment-caused impairments.
• Phase timings lead to owned improvements rather than individual performance scoring.

MTTR becomes useful when it exposes where the response system loses time. Define the clock, keep the source data auditable, show the distribution, and improve the slow phase. The mean can then summarize the work without hiding the incidents that matter most.