Define downtime before measuring it
A downtime number is only useful when everyone agrees on its scope. Decide which assets, shifts and event types are included, when an event starts, when it ends and whether planned maintenance is reported separately from unplanned loss of service.
Record both the failed asset and the operational effect. A vehicle can be unavailable without stopping a job when a suitable replacement is ready. The same failure can stop a crew when there is no replacement. Those are different operational consequences and should not be assigned the same cost by default.
A minimum event record
- Asset, site, shift and responsible team.
- Event start, service-restored time and data source.
- Planned or unplanned classification.
- Failure mode, cause code and corrective work.
- Direct labour, parts and external repair cost.
- Operational effect, replacement used and affected work.
Build a cost model from your records
There is no single fleet-downtime cost that can be applied safely to every vehicle or machine. Build a model for the event scope you are evaluating. Keep each component visible so reviewers can see what is measured, modelled or excluded.
A simple operational scenario is: downtime events per period × average duration × cost per hour. The hourly input may include idle labour, replacement hire or delayed output, but only when those costs are attributable and not already counted elsewhere. Add repair cost separately if it is not part of the hourly figure.
Use the downtime cost calculator to document that input-based scenario. Its example values are not an industry benchmark, quote or forecast of a MapTrack result.
Diagnose causes, not averages
Generic cause percentages do not tell you what to fix in your fleet. Rank your own records four ways: total downtime hours, number of events, direct cost and recurrence. The asset with the most failures may not be the one creating the greatest operational loss.
Separate symptom from cause. “Won't start” is a symptom. Battery condition, wiring damage, an operating practice or an incomplete prior repair may be the cause. Keep an “unknown” category rather than forcing weak evidence into a precise label, then improve the record as the investigation progresses.
Choose maintenance by failure mode
The US Department of Energy's current guidance distinguishes reactive, preventive, predictive and reliability-centred approaches. It does not prescribe one universal fleet interval or saving. A sound programme chooses the approach for each material failure mode.
- Follow statutory, safety and manufacturer requirements where they apply.
- Use time or meter schedules when the task and interval have a clear basis.
- Use condition data only when the measure is sufficiently reliable to support the decision.
- Allow deliberate run-to-failure where the consequence is understood and acceptable.
More scheduled work is not automatically better. Unnecessary work has a cost and can introduce faults. Record the reason for an interval and review it against completed work, findings and failures.
Use tracking data carefully
A shared asset record can reduce the effort needed to find service history, current responsibility and open work. Where compatible meter data is configured, it can also support a schedule based on kilometres or operating hours. These are workflow mechanisms, not proof of a downtime reduction.
Treat GPS, meter and diagnostic data as observed inputs with known provenance. Coverage depends on the device, integration, installation, connectivity and operating environment. Missing data is not evidence that an asset did not move, operate or develop a fault.
Run a controlled pilot
Start with a clearly defined asset group and the failure modes creating the greatest documented impact. Write down the change, target, measurement window, comparison method, costs and stop conditions before the pilot begins.
A 2021 NIST-published observational study used 71 usable, self-reported responses from US discrete manufacturers. The group characterised as less reactive reported 52.7% less unplanned downtime. The authors say this grouped comparison should be treated as anecdotal evidence and note limitations including the small sample and self-reported data. This is an association in that sample, not a causal estimate for a fleet or a forecast of a software outcome. Read the NIST publication before using it as context.
Measure improvement consistently
Compare like with like. Preserve the event definition, asset scope, planned-time denominator and cost method across the baseline and pilot. Report changes in utilisation, workload or asset mix that could affect the result.
- Availability: serviceable planned time divided by total planned time, using a documented denominator.
- Downtime burden: total hours and events, split by planned and unplanned classifications.
- Restoration: median and distribution of time to restore service, not only an average.
- Reliability: repeat failures and time or use between comparable failures.
- Execution: due, completed, overdue and deferred work, with reasons.
- Economics: observed direct costs plus explicitly modelled operational effects, without double counting.
Set thresholds from operational requirements and your measured baseline. A target that is appropriate for a critical response vehicle may be wasteful for a low-consequence spare asset. The objective is a defensible decision for the fleet you operate, not a generic percentage.
