Equipment Downtime: Separate Repair Delays From Idle Time

When a machine is not producing, downtime can sound like one clear problem. In a heavy civil fleet, the word may describe a failed hose, a machine waiting for a mechanic or a serviceable excavator parked because the project has no work. Those situations need different decisions. Treating them as one category conceals the difference between maintenance constraints and planning problems.

Consistent classification does not promise lower costs. It makes the operational review more useful: teams can agree what happened, identify uncertainty and assign the next action. CFMA and AEMP’s Heavy Equipment Comparator emphasizes common terminology and calculation methods. A precise-looking total is not useful if the field and shop disagree about what it measures.

Define unavailable before measuring it

Agree when an asset cannot perform its intended work. Decide how planned maintenance is reported and when readiness must be confirmed. Put the boundaries in writing. An asset without an assignment may be serviceable, while an assigned machine may be awaiting a repair. Location and meter readings do not resolve that distinction on their own.

Keep engine-running idle separate

Idle time commonly describes an engine running without the activity classified as active work. Engine-off equipment with no assignment is better described as parked or unassigned, not engine idle. A stationary machine may still perform useful work. Check the source definition and machine role before interpreting any reported idle total as avoidable waste.

Use a small set of reason categories

Separate unplanned repair, planned service, parts waiting, specialist waiting, transport, weather or access delays, unassigned equipment and unknown status where useful. Categories should explain the next decision, not create a complicated taxonomy crews cannot apply. Unknown with a named verification owner is more honest than a confident guess. Preserve the reported symptom rather than inventing a diagnosis.

Capture event time and entry time

Record asset identity, site, when the issue began, when it was entered and who reported it. A Friday note about a Tuesday breakdown should not appear to be a Friday event. Capture diagnosis, approval, parts and repair milestones when relevant. Define the duration you intend to measure: report-to-readiness is different from technician working time and may include weekends or access delays.

Identify the constraint, not only the total

For each unavailable machine, ask what is preventing the next step. It may be approval, diagnosis, a part, a qualified technician, access or verification after repair. A total duration cannot reveal that on its own. Name the responsible person and check-in point. Do not assign every hour to the shop when another team controls the immediate constraint.

Review unassigned machines against demand

For equipment believed serviceable, confirm readiness and compare upcoming work. Check location, attachments, transport and whether the asset is held for a critical window. Parked does not automatically mean surplus. Review a potential move with the receiving project before booking transport or adding another rental. State assumptions if the work schedule is still provisional.

Use trends as investigation prompts

Repeated faults, long waits before diagnosis and recurring unassigned periods deserve review. A pattern is not proof of cause. Compare similar assets and conditions, inspect underlying records and separate planned service from failures. The CFMA discussion of maintenance effectiveness provides broader measurement context than a repair cost total alone.

End with a short action list

Record the asset, issue, next step, owner and review date. Begin the next meeting with items still open. Correct stale status before arguing about a historical total; the equipment needed tomorrow deserves attention first. Consistent follow-through gives the classifications value.

Align terminology with equipment downtime and equipment idle time. Bring your current review process to a goAardvark demo to discuss fleet visibility and the work around resolving exceptions.