You Do Not Have a Fault Code Problem. You Have a Triage Problem.

Ask a maintenance director about what changed most in the last decade, and you will rarely hear "we lost visibility." The opposite happened. Modern assets broadcast continuously. Engine, aftertreatment, brakes, transmission, tires, body equipment – all of it reports, all the time.

The result is a genuinely new problem: fault code prioritization. A fleet that once knew too little now receives more diagnostic events in a week than any human team can meaningfully read. And a fault code that nobody has time to interpret is functionally the same as no fault code at all – except that it also generates alert fatigue, which is worse than silence, because it teaches your team to ignore the channel.

The question is no longer whether you can see fault codes. It is whether your organization can convert them into decisions at the rate they arrive.

Why fault code volume became the problem

A single diagnostic event on a heavy-duty asset arrives as a structured message: a parameter identifying the affected system and a failure mode describing how it is behaving abnormally. It is precise, and on its own it is useless for planning.

It does not tell you whether the condition is getting worse. It does not tell you if this asset is thirty miles from a terminal or six hundred. It does not tell you whether the same code has appeared eleven times this month and cleared itself each time. It does not tell you whether the truck is scheduled into a bay next Tuesday anyway.

Every one of those missing pieces is available somewhere in your operation. They just tend to live in different systems, owned by different people, with no shared moments where they meet. So, a maintenance team ends up doing the join manually, one code at a time, and only the codes loud enough to demand attention. Everything else queues, and the queue is where the money goes.

The three questions that turn a code into a decision

Prioritization is not a scoring algorithm. There are three questions answered in order.

1. How bad is it right now?

Severity is the obvious question, and the only one most alerting system answers. It is necessary and insufficient. A derate condition and a minor sensor fault are not comparable to events, and a system that pages a human for both has already failed.

2. Where is it heading?

This is the question that separates useful diagnostics from noise, and it requires history. A code that has appeared once means something quite different from the same code appearing with increasing frequency over three weeks. A slow degradation trend on an aftertreatment component is a schedulable repair. The same component failing abruptly is a tow.

You cannot see trajectory from a single event. You see it from the pattern, which means the value is in the retained history, not in the alert.

3. What is this asset doing next?

Context is what converts a technical fact into an operational decision. The same code on two assets deserves two different responses if one is deadheading back to the yard, and the other is loaded, under a delivery commitment, and eleven hours from the nearest qualified shop.

This is the question maintenance systems most often cannot answer because the answer lives in dispatch.

What fault code prioritization looks like when it works

The practical output is not a ranked list of codes. It is a small number of standing response tiers, agreed in advance, that a dispatcher or shop lead can apply without escalation.

• Stop now. Safety-relevant or imminent damage conditions. The response is scripted, the authority to pull off the asset is pre-delegated, and nobody debates it right now.
• Next available by. Real, degrading, but not immediate. The asset finishes its current duty cycle and is routed to service on arrival. This tier is where the largest cost avoidance sits, and it is the tier most fleets do not formally have.
• Bundle at the next PM. Legitimate, non-degrading, and cheaper to fix inside work that is already scheduled. Bundling is how a diagnostics program pays for itself without adding bay hours.
• Suppress, but retain. Known-benign codes, or conditions already ticketed. Suppressed from the alert stream, retained in history, and reviewed on a cadence – because "benign" is a judgment that should be revisited, not a permanent classification.
• Share of repairs that were planned versus unplanned. The headline number. If prioritization is working, a planned share rises.
• Time from the first occurrence to the disposition. How long does a code sit before someone decides what to do with it? This is the triage metric.
• Repeat events before acting. How many times is a condition reported before anyone responded? High counts indicate that the queue is not being worked.
• Roadside events preceded by a prior related code. The most uncomfortable and most useful number in the set. Every one of these was a missed schedulable repair.
• Suppression accuracy. How often does a suppressed code later turn into a real failure? This is what keeps the suppress tier honest.

The point of the tiers is that they remove the per-event debate. The decision is made once, at the policy level, rather than fifty times a week under time pressure.

The half of this that is not technology

Two things reliably determine whether a diagnostics program works, and neither is a feature.

Someone owns a triage by name. Not a department – a role, with defined hours and a defined backup. Diagnostic streams do not respect shift boundaries, and a queue that nobody owns overnight is a queue that gets cleared by deletion in the morning.

Dispatch and maintenance share the decision. If maintenance can flag an asset, but only dispatch can pull it, and the two run separate meetings on separate systems, the tiers above are aspirational. This is an operating-model question that surfaces during a technology rollout and gets misdiagnosed as a technology problem.

Fleets that skip these two items typically arrive at the same outcome: a well-configured system generating well-prioritized alerts that nobody acts on inside the window where action was cheap.

What to measure

Prioritization is measurable, and it should be measured on outcomes rather than on alert volume:

• Share of repairs that were planned versus unplanned. The headline number. If prioritization is working, a planned share rises.
• Time from the first occurrence to the disposition. How long does a code sit before someone decides what to do with it? This is the triage metric.
• Repeat events before acting. How many times is a condition reported before anyone responded? High counts indicate that the queue is not being worked.
• Roadside events preceded by a prior related code. The most uncomfortable and most useful number in the set. Every one of these was a missed schedulable repair.
• Suppression accuracy. How often does a suppressed code later turn into a real failure? This is what keeps the suppress tier honest.

Start with the uncomfortable audit

Before evaluating any platform, run one exercise. Take your last twenty roadside failures and check whether the asset transmitted a related diagnostic event beforehand. Then check what happened to that event.

Most fleets find that the majority had a prior signal. That finding is not a criticism of the maintenance team. It is a measurement of the gap between the data arriving and the organization's capacity to act on it – and it is the most persuasive internal case for fixing the triage layer you will ever assemble.