---
title: "How to cut maintenance response time"
description: "Response time runs from a machine stopping to a technician at it. Split it into four segments, time each one, and fix the one where your slowest stops wait."
category: "Maintenance and reliability"
author: "Reliability Engineering Team"
published: "2026-10-26"
updated: "2026-11-02"
source_url: "https://www.iotflows.com/blog/maintenance-response-time/"
---
> Question: How do we get a technician to a stopped machine faster?

## Key takeaways

- Maintenance response time runs from the moment a machine stops to the moment a technician arrives, before any repair starts.
- Split response time into detection, reporting, assignment and travel, because each segment has a different fix.
- Take the stop time from the machine, not from the work order, or detection and reporting drop out of the measure.
- Report the median and the slowest stops every week, because a few long waits pull the mean far from a typical stop.
- Fix the segment where your slowest stops lose their minutes first, which is often detection or reporting rather than travel.

You get a technician to a stopped machine faster by splitting response time into its four segments and fixing the slowest one. The machine stops, somebody notices, somebody reports it, a technician is assigned, and the technician arrives. Time each gap from timestamps you already keep, read the median and the worst stops instead of the mean, and attack the segment where your slowest stops lose their minutes.

This guide is for maintenance leads. It walks through the anatomy of a repair stop, one hypothetical week of stops computed two ways, and the fix that fits each segment.

## What is maintenance response time?

Maintenance response time is the time from a machine stopping on a fault to a technician arriving at it.

> **Definition.** **Maintenance response time** is the time from the moment a machine stops on a fault to the moment a maintenance technician arrives at the machine, before any diagnosis or repair starts.

NIST researchers who built maintenance indicators from real work orders call the same gap *time to dispatch*: from when the machine is down until the maintenance technician arrives.[1] It is the part of a stop that skill doesn’t shorten. A better technician repairs faster but arrives no sooner.

A *repair stop* here is an unplanned stop that needs a technician and gets a [work order](/docs/get-started/glossary/#work-order). Changeovers and material waits don’t count, since nobody from maintenance responds to them.

## Where does response time sit in a repair stop?

Response time covers the first four of a repair stop’s eight segments; the other four are the repair. A repair stop passes nine moments, from the machine stopping to the machine running again, and each gap between two of them is a segment you can time.

Figure: A repair stop as eight segments. Detect, Report, Assign and Travel run from the machine stopping to the technician arriving, bracketed as response time. Diagnose, Parts, Fix and Restart run on to the machine running again, bracketed as repair.

*Response time ends when the technician reaches the machine; everything after it is the repair.*

| Segment | From | To | Part of |
|---|---|---|---|
| Detection | Machine stops | Somebody notices | Response |
| Reporting | Somebody notices | Work order opened | Response |
| Assignment | Work order opened | Technician assigned | Response |
| Travel | Technician assigned | Technician at the machine | Response |
| Diagnosis | Technician at the machine | Cause found | Repair |
| Parts | Cause found | Parts in hand | Repair |
| Fix | Parts in hand | Fault fixed | Repair |
| Restart | Fault fixed | Machine running | Repair |

Parts runs to zero when the part is already at the machine. Restart includes the first good part where a quality check applies.

The split matters because the two halves have different owners. Response is a process problem: who sees the stop, how it reaches maintenance, and who picks it up. Repair is a skill and parts problem.

A plant that reports only total stop length can’t tell a slow repair from a slow phone call. For example, a 90-minute spindle stop on a Haas VF-2 could be 10 minutes of response and 80 of repair, or the other way around. The two need opposite fixes.

## How do you measure each segment?

You measure each segment as the gap between two timestamps, and most plants already record some of the nine. NIST’s list of work order timestamps runs the same way: machine down, work order start, technician arrives, problem found, parts ordered and received, problem solved and machine up.[1]

| Timestamp | Where it usually lives | If it’s missing |
|---|---|---|
| Machine stops | Machine monitoring or a PLC | Operator’s call time, labeled |
| Somebody notices | Rarely recorded | Merge into reporting |
| Work order opened | CMMS created time | Time on the paper slip |
| Technician assigned | CMMS assignee change | Work order opened |
| Technician arrives | Status set at the machine | Ask for a tap on arrival |
| Machine runs again | Machine monitoring or a PLC | Work order closed, labeled |

Pair each work order with its stop by machine and time: the first stop on that machine before the work order opened.

Three rules keep the numbers honest:

- **Take the stop time from the machine.** A work order’s created time starts the clock after detection and reporting, so both segments vanish. NIST notes that the time elements most often calculated are work order start and completion, and that accurate results need precise times, down to the second.[1]
- **Define arrival once.** Ask technicians to set the work order in progress when they reach the machine, not when they pick it up at the shop. Otherwise travel reads as zero and diagnosis absorbs the walk.
- **Accept a merged segment.** Without automatic detection, nobody records when a stop was noticed. Track detection and reporting together, from stop to work order, until you can split them.

## Why track the median, not the mean?

Track the median and the slowest stops because response times are skewed: most stops are answered in minutes, and a few wait for hours. The NIST/SEMATECH statistics handbook explains the effect. In a skewed distribution the mean is pulled toward the long tail, and extreme values in the tails distort the mean, while the median depends only on rank.[2]

Report three numbers every week:

- **Median.** The typical stop: half are answered faster, half slower.
- **90th percentile.** The *90th percentile* is the time that nine stops in ten meet or beat. It shows the slow end without letting one outlier set the number.
- **Stops over target.** The count, with the machine and shift of each one. These are the stops you investigate.

Show the mean only beside the median. When the two sit far apart, that gap is the finding: a few stops wait far longer than the rest. The same trap applies to repair time, where one long wait for parts can double a week’s mean.

## One week of stops, computed two ways

For example, take a hypothetical five-machine CNC line that runs two staffed shifts and unattended overnight, with one technician on call at night. In one week it has 10 repair stops. Each row gives the minutes in each response segment.

| Stop and total | Detection | Reporting | Assignment | Travel |
|---|---|---|---|---|
| Mon 07:40, Mill 1: 12 min | 1 | 3 | 3 | 5 |
| Mon 13:15, Lathe 2: 14 min | 2 | 3 | 4 | 5 |
| Tue 09:30, Mill 3: 15 min | 1 | 4 | 4 | 6 |
| Tue 22:50, Lathe 2: 95 min | 40 | 20 | 30 | 5 |
| Wed 10:05, Grinder: 16 min | 2 | 4 | 4 | 6 |
| Wed 14:55, Mill 1: 28 min | 3 | 10 | 10 | 5 |
| Thu 08:20, Mill 3: 18 min | 2 | 5 | 5 | 6 |
| Thu 11:40, Saw: 20 min | 3 | 5 | 6 | 6 |
| Fri 04:30, Lathe 2: 160 min | 70 | 35 | 45 | 10 |
| Fri 13:10, Mill 1: 22 min | 3 | 6 | 7 | 6 |
| All 10 stops: 400 min | 127 | 95 | 118 | 60 |

Sample data for a hypothetical line. Minutes per segment; each row sums to the stop’s total.

#### Worked example: Response time for one week on a five-machine line

- **Per stop:** the 10 totals sum to 400 minutes, so the mean is 400 ÷ 10 = 40.0 minutes.
- **Per segment:** detection 127 ÷ 10 = 12.7, reporting 95 ÷ 10 = 9.5, assignment 118 ÷ 10 = 11.8 and travel 60 ÷ 10 = 6.0 minutes. Their sum is 12.7 + 9.5 + 11.8 + 6.0 = 40.0 minutes, which matches.
- **Median:** sorted, the totals are 12, 14, 15, 16, 18, 20, 22, 28, 95 and 160, so the median is (18 + 20) ÷ 2 = 19 minutes.
- **90th percentile:** the 9th of the 10 sorted stops, 95 minutes.

**Result:** Mean 40.0 min, median 19 min, 90th percentile 95 min

Figure: Ten response times ranked from 160 to 12 min. Eight daytime stops take 12 to 28 min; two overnight stops take 95 and 160. The median line sits at 19 min and the mean line at 40 min, where no stop falls.

*The mean of 40 minutes describes no stop; two overnight stops pull it up. Sample data.*

No stop took 40 minutes. Eight were answered in 12 to 28 minutes, and two overnight stops took 95 and 160. Those two carry 255 of the 400 minutes, 63.8% of the week’s response time.

The segment means mislead the same way. Detection averages 12.7 minutes, the largest segment, as if every stop went unnoticed for a quarter of an hour. On the eight daytime stops, detection is 1 to 3 minutes; the two overnight stops supply 110 of its 127 minutes. Travel, the segment people blame first, is 5 to 10 minutes on every stop.

Reading only the mean, this plant would move the maintenance shop or buy carts. The median and the two worst stops say the problem is overnight: nobody sees the stop, and once somebody does, the call reaches the on-call technician slowly.

## How do you shorten each segment?

Each segment has its own fix, and a fix for one segment does nothing for the others.

### Detection: let the machine report the stop

Detect stops from the machine signal instead of from somebody walking past. A sensor or controller signal records the stop to the second on every shift, including unattended ones. On the example line, automatic detection with an alert at 10 minutes would cap overnight detection near 10 minutes, instead of 40 and 70.

### Reporting: open the work order from the stop

Open the work order where the stop is recorded, with the machine, the reason, the stop time and the operator’s note already in it. Every handoff between operator, supervisor and maintenance office adds minutes and loses the stop time. Which stops qualify, and who triages them, is in [how to turn a classified stop into a work order](/blog/work-orders-from-downtime/).

### Assignment: route the alert to a named person

Send the stop alert to the technician on duty for that machine, not to a shared inbox. Set the first alert above the machine’s normal changeover, and a later one to the maintenance lead when nobody has taken the work. At night, the alert goes to the on-call technician’s phone. Thresholds, channels and alert fatigue are covered in [machine down alerts people act on](/blog/machine-down-alerts/).

### Travel and parts: stage tools and kits at the cell

Travel is rarely the long segment, so fix it last. Keep the common tools on a cart at each cell, and kit the 2 or 3 parts that fail most on each machine.

Parts sit in repair time, not response time. A technician who arrives without them is back at the stores 5 minutes later, though, and the walk is lost. For the whole breakdown, parts wait included, see [how to reduce machine downtime](/blog/reduce-machine-downtime/#duration).

## Route every stop to maintenance automatically

A SenseAi sensor on each machine detects every stop in seconds, with no PLC, on every shift. A [Machine Down alert](/docs/alerts/asset-event-rules/#machine-status) fires at a warning time and a critical time, by email, push, SMS or chat.

The operator who classifies the stop opens a work order in the same step, prefilled with the machine and the reason. An event rule opens one with no operator at all, for an abnormal shock or a critical health alert. The work order’s [activity log](/docs/maintain/work-order-detail/#activity-log) records every status change, so arrival comes from a record.

At RNPSA, “critical vibration anomalies auto-escalate work orders,” and “response time dropped 50%,” with “maintenance no longer waiting for shift handoffs or email chains,” as [RNPSA’s story](/customers/rnpsa/) describes. See how [Maintain](/platform/maintain/) works.

## Which segment should you attack first?

Attack the segment where your slowest stops lose the most minutes, not the one with the largest mean. Take your 90th-percentile stops, split each into segments, and look for the segment that is long on those stops and short on the rest.

- **Choose detection** when the slowest stops fall on unattended or thinly staffed shifts, or when the gap from stop to work order ranges from 1 minute to an hour.
- **Choose reporting** when stops are seen quickly but the work order opens 10 or more minutes later, or only at the next shift.
- **Choose assignment** when work orders sit open with nobody on them, at shift change or overnight.
- **Choose travel** only when it is long on most stops, not a few: a maintenance shop at the far end of a large building, or one technician covering two buildings.

> **Do you need new software to start?**
>
> No. Two weeks of stop times from the machines and the times written on work order slips show which segment holds the minutes. Add tools once you know which segment you are fixing, then compare the median and 90th percentile on the same machines and shifts four weeks later.

## Questions

### What is a good maintenance response time?

No published benchmark fits every plant. Set a target per machine from what an hour of its downtime costs, for example 15 minutes for the machine that paces the line and an hour for a machine with spare capacity beside it. Then track the share of stops that meet the target each week, next to the median.

### Is response time the same as MTTR?

No. MTTR, mean time to repair, usually covers the whole stop, from the machine going down to running again, with diagnosis, parts and the fix inside it. Response time is only the first part, up to the technician arriving. A plant can halve its response time and barely move MTTR when waiting for parts dominates its repairs.

### Should response time end when the technician arrives or when work starts?

End it at arrival, when the technician is at the machine. Work often starts later, after lockout, a look at the machine history or a call for a second skill, and that time belongs to diagnosis. If your technicians only record when they start work, use that time and label the report, so nobody compares the two measures.

### Do changeovers and planned stops count in response time?

No. Count only unplanned stops that needed a technician: breakdowns, crashes, leaks and electrical faults. Changeovers, material waits and breaks have no maintenance response to measure. Including them adds entries with no technician in them, which pulls the median down and hides the slow repairs you are trying to find.

## Sources

1. [Developing Maintenance Key Performance Indicators from Maintenance Work Order Data](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=924883), National Institute of Standards and Technology (Brundage, Sexton, Hoffman, Moccozet, Morris), ASME MSEC 2018, accessed Oct 30, 2026
2. [NIST/SEMATECH e-Handbook of Statistical Methods, 1.3.5.1 Measures of Location](https://www.itl.nist.gov/div898/handbook/eda/section3/eda351.htm), National Institute of Standards and Technology, accessed Oct 30, 2026