Mechanic Guides
Pending vs Confirmed Trouble Codes: What the Status Changes in Your Diagnosis
Interpret pending and confirmed DTCs without turning status into a parts diagnosis. Includes a technician worksheet for codes, symptoms and follow-up evidence.
Published · 5 min read
Quick answer
Pending and confirmed describe how a diagnostic result is recorded under the monitor's logic. A pending code can appear before the confirmation criteria are met; a confirmed code records that those criteria were met. Neither status identifies the failed part, establishes that the fault is happening now, or replaces the applicable diagnostic procedure.

A customer reports an intermittent hesitation. The scan shows a pending code, but the warning lamp is off and the symptom is absent in the bay. The useful next move is to preserve that result and relate it to the complaint. Ignoring it because it is pending loses evidence; ordering a component because it is a code skips diagnosis.
For a professional shop, the distinction helps organize the next check and the handoff. It does not decide the repair by itself.
What the status tells you
A pending DTC can record a detected condition before the monitor's confirmation criteria have been met. A confirmed DTC records that the applicable confirmation criteria were met. Confirmed does not mean the condition is necessarily present at this instant, and pending does not mean the report is meaningless.
Ford's 2017 diesel OBD operation summary, pages 201-202, shows both a pending-to-confirmed sequence and monitoring strategies with different confirmation behavior. It also ties changes in stored status to monitoring results, rather than simply to how many times someone turns the key. This is a historical manufacturer example, not a universal trip-count rule.
Record the exact labels your tool displays. If the same identifier appears under more than one status, keep those observations. Do not count them as separate failed parts or force them into mutually exclusive boxes. Use current vehicle and tool documentation to interpret the reported categories.
Capture the code and the complaint separately
Start the record with the customer concern in the customer's terms, followed by what the technician has actually reproduced. Then attach the scan result. That order prevents the code description from silently replacing the original complaint.
Save these fields before deciding the next step:
- Vehicle configuration, scan time and mileage.
- Tool version, selected scan mode and responding module.
- Exact code identifier and every displayed status associated with it.
- Commanded MIL status and observed lamp behavior, recorded separately.
- Available freeze frame or other event data, with a reference to the original capture.
- Known recent repairs, code clearing or battery disconnection; mark unknown history explicitly.
Do not promise that every pending code has a useful event snapshot. Record what the vehicle and tool actually provide. The freeze-frame guide provides a separate framework for reading an available snapshot without treating it as a live measurement.
Avoid two shortcuts
Pending means wait until the lamp turns on. That is not a diagnostic plan. Decide the next action from the complaint, observed condition and applicable procedure. A status label alone is not a safe-to-drive verdict. Do not delay investigating a concerning symptom solely to obtain a different label.
Confirmed means replace the named component. Confirmation concerns the monitor's criteria. It does not prove that the component named in a code description caused the result. Preserve the working hypothesis separately and select a check that can support or reject it.
Also keep lamp state separate from stored information. A note that only says light off cannot substitute for the actual scan report. If the vehicle reports a permanent code, use the permanent DTC after repair guide for that distinct question.
A fictional handoff with a useful next action
In an invented training case, Technician A saves a pending result while the customer's hesitation is not reproduced. The handoff includes the module, identifier, available event data and the conditions the customer described. The applicable procedure identifies the conditions required for the next check. No repair has been performed.
Technician B later obtains a confirmed result for the same identifier and module. That new record is added with its timestamp and test conditions. It supports a change in recorded status; it does not retroactively prove that the original hypothesis was correct. The actual test results still determine the repair recommendation.
Alternatively, suppose the pending result is absent on the next scan. Document the change, whether the relevant monitoring conditions were completed, and whether the complaint was verified. Do not fill those unanswered fields with an assumed pass. An absent code and a reproduced, resolved complaint are different pieces of evidence.
Close the handoff with a question someone can answer
Use the worksheet to name the next prescribed check, its required conditions, the person responsible and the evidence to capture. Keep the original exports attached. If two sessions used different scan scopes, document that limitation before comparing them; the generic vs enhanced OBD2 guide explains why scope matters.
The customer-facing note should distinguish the reported symptom, confirmed observations, proposed work and unresolved questions. To discuss keeping those records connected across your shop, request STEP early access.