How to calculate MTTR — and make the number trustworthy

MTTR definition

MTTR means Mean Time to Repair — the average time it takes to restore an asset after a failure event. Plants use it to compare repair speed across assets, shifts, or periods, and to see whether process changes (kits, escalation, better handoffs) actually shortened restores.

MTTR is only useful when:

• Every counted failure is a real restore event on a defined asset
• The clock definition is the same every time
• You compare like with like (same asset class or line family)

A single plant-wide MTTR that mixes packaging micro-stops with major utility outages will mislead you.

The MTTR formula

Use this formula for a chosen period and asset set:

MTTR = Σ repair_time_i / n_failures

Where:

• repair_time_i is the duration of failure *i* under your chosen definition
• n_failures is the number of failure events in the set
• Units stay consistent (minutes or hours)

Example structure: if five failures took 40, 55, 30, 90, and 45 minutes under your definition, MTTR = (40+55+30+90+45) ÷ 5 = 52 minutes.

What time window to include

This is where plants argue. Pick one definition, write it down, and stick to it.

Common options:

1. Detection → restoration — from when the stop is known until the asset is back producing. Includes diagnosis, waiting for people, waiting for parts, and repair.
2. Wrench time only — from when a technician starts active repair until the machine is ready. Excludes queue and parts wait.
3. Hybrid reporting — publish total restore time and active repair time as two metrics so parts delays do not hide inside “labor.”

Practical rule: if leadership cares about lost production minutes, prefer a restore-time definition (or report both). If you are coaching technician execution, wrench time is cleaner — but label it clearly so nobody confuses the two.

Also decide whether planned maintenance windows count as “failures.” Usually they should not enter MTTR; keep planned downtime separate.

Worked example

Suppose packaging line P2 had four unplanned stops in a week. Your definition is detection → restoration (including parts wait):

• Event A: 25 minutes
• Event B: 70 minutes (including 40 minutes waiting on a belt)
• Event C: 35 minutes
• Event D: 50 minutes

MTTR = (25 + 70 + 35 + 50) ÷ 4 = 45 minutes.

If you recalculate using wrench time only (subtract the 40-minute parts wait from B):

• Durations: 25, 30, 35, 50 → MTTR = 35 minutes

Same week, same line, two different stories. Publish the definition next to the number or the metric will not survive a production meeting.

MTTR vs MTBF (brief)

• MTTR — how long restores take after failure (repair / restore speed)
• MTBF (Mean Time Between Failures) — how long assets run between failures (reliability / failure frequency)

You can have a short MTTR and still lose the week if failures are frequent. Downtime improvement usually needs both: fewer repeats (better reliability / PM) and faster restores (better diagnosis, kits, ownership). For actions that cut lost time, see [how to reduce equipment downtime](/guides/reduce-equipment-downtime).

How a CMMS improves MTTR data quality

Spreadsheets and chats rarely produce trustworthy MTTR because events lack consistent start/complete timestamps, asset identity, and parts context.

A [CMMS](/guides/what-is-a-cmms) improves the raw data when:

• Each failure becomes a work order on the asset
• Start and complete times are recorded when work is claimed and finished
• Notes and fault detail survive shift change ([how to write a work order](/guides/how-to-write-a-work-order))
• Parts usage shows whether restores were blocked by inventory

MTTR then comes from summing real event durations — not from reconstructing the week from memory on Friday afternoon.

Actions that actually reduce MTTR

Dashboards do not shorten restores. These do:

1. Better first-pass information — asset, fault detail, and impact on the work order so diagnosis starts sooner
2. History on the machine — last failure mode and fix notes visible before the wrench turns
3. Kits for top failure modes — pre-staged parts for the stops you already know will return
4. Clear escalation — when a job exceeds a time threshold, who gets called
5. PM that removes known wear failures — fewer “surprise” restores on the same components
6. Weekly review of slow restores — attack the longest events and repeat assets, not average vanity charts

Corivo supports the data side of this loop: work orders with timing, ownership, and parts on the asset so MTTR is computed from plant history instead of guessed after the fact.