STEP Diagnostics
STEP Diagnostics
Mechanic guides

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.

Download the DTC status and follow-up worksheet
Concept illustration of two blank diagnostic record cards in different positions on a workshop bench
Concept illustration; not a product screen, real vehicle record or repair 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.

Continue with STEP

Keep the evidence and the next test together

STEP is being built for guided diagnostic work with vehicle context, sources and completed checks. Join early access and share the workflow your shop needs.

Request Early Access