Debugging EV Charger Faults
Most reported charger faults are not the charger. The single most useful thing an operation can do is separate charger, supply, installation and vehicle causes before dispatching anyone, because each leaves a different signature and only one of them is a warranty claim.
Method rather than any particular fault: what evidence each class of problem leaves, the order in which to look, the misdiagnoses that cost the most time, and how to build an operation where the common cases resolve remotely.
For An operator, installer or manufacturer facing faults they cannot categorise, and the cost of dispatching engineers to units that turn out to be working.
Send us a fault to debugFour causes that look identical in a ticket
A driver reports that charging did not start. That single sentence covers four completely different problems with four different owners, and treating them as one is why support costs what it does.
- 1
The charger
A genuine hardware or firmware fault. This is the smallest of the four categories in our experience and the one everybody assumes first.
- 2
The supply
A protective device upstream, a lost phase, or a site that has run out of headroom at the exact hour everyone plugs in. The charger is working and correctly refusing.
- 3
The installation
Earthing, termination, or a protective device chosen for the wrong duty. Frequently intermittent, frequently weather related, almost never diagnosed as installation on the first visit.
- 4
The vehicle
An onboard charger negotiating badly, a car that caps well below what the driver expected, or a locked vehicle that will not accept a session. No amount of charger replacement fixes it.
An operation that has not separated these is managing a hardware problem it may not have. Our own unit failure rate runs near 0.5 percent, about one charger in two hundred, and it is a much smaller number than our call volume.
What each cause leaves behind
Swipe to compare
| Signature | Usually means | Check next |
|---|---|---|
| Fault appears on one vehicle model only | Vehicle side negotiation or a timing assumption in firmware | Reproduce with a simulator, compare against another model |
| Fault clusters at one time of day | Supply headroom, not the charger | Site maximum demand at that hour |
| Fault appears after rain or humidity | Installation: earthing, termination or ingress | Physical inspection, insulation readings |
| Fault appears across a whole site at once | Supply or backend connectivity | Upstream protection, then the network path |
| Fault appears across a whole fleet at once | A firmware release or a platform change | What changed, and when, on both sides |
| Session starts then stops seconds later | Pilot or contactor sequencing, or a vehicle rejecting the offer | The OCPP trace and the local log together |
| Backend shows the session, driver says nothing happened | Metering or transaction reporting, not delivery | Meter values against the vehicle's own record |
The order to look in
Cheapest and most conclusive first. Almost every operation does this in the wrong order, starting with the physical unit because that is the thing they own.
- The OCPP trace, because it is free, immediate, and shows whether the charger was even asked to do anything
- The device log, if the firmware records one worth reading
- The pattern across time, vehicle and site, which is the step most often skipped and most often decisive
- Site electrical data, if the pattern points upstream
- A physical visit, last, and only with a hypothesis to test
A visit without a hypothesis produces the finding that no fault was found, which costs the same as a real visit and resolves nothing.
Misdiagnoses that cost the most
- 1
Replacing the unit
The default response, and it appears to work whenever the fault was intermittent. The fault returns weeks later on the replacement, by which point the connection is lost.
- 2
Blaming the vehicle
Sometimes correct, and a very convenient conclusion. It becomes a habit that hides real firmware faults for months.
- 3
Treating a protection trip as a nuisance
A protective function detecting a real installation fault is doing its job. Raising the threshold or resetting it repeatedly converts a diagnosable fault into a safety problem.
- 4
Patching a supply problem in firmware
It works, and it creates a second fault later in a form that is never connected to the first.
Building an operation that diagnoses remotely
The goal is not to be better at site visits. It is to need fewer of them, and that is decided by design choices made long before the first fault.
- Firmware that records enough locally to explain itself after the event
- Traces retained long enough to look at a fault reported three days later
- Fault codes that distinguish causes rather than reporting that something failed
- A remote path to read logs without dispatching anyone
- Fault history per unit, so a repeat offender is visible as a pattern rather than as five unrelated tickets
Firmware that logs nothing cannot be debugged remotely, and that is itself a finding worth acting on before the next fault arrives.
Want this applied to your own site?
Send us a fault to debugRelated
Technically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
How many reported faults are actually the charger?
In our experience a minority. Unit failures across our AC fleet run near 0.5 percent, roughly one in two hundred, while support call volume is considerably higher. Most calls are supply, installation or vehicle.
What is the single most useful piece of evidence?
The OCPP trace around the failure, with timestamps. It is free to collect and it resolves a large share of reports on its own by showing whether the charger was asked to do anything.
Can you debug chargers you did not manufacture?
Yes. Protocol level diagnosis works on any OCPP charger. Going deeper than that depends on what logging and access the unit provides.
Our chargers do not log anything useful. What now?
Then remote diagnosis is not available and every fault costs a visit. Fixing the logging is usually worth more than fixing the fault that prompted the conversation.
How do we tell an installation fault from a charger fault?
Installation faults are usually intermittent and environmental. A fault that appears after rain, or only at one bay on a site, is pointing at the installation rather than at the unit.
Dispatching engineers to chargers that turn out to be fine?
Send us a month of fault tickets and the traces behind them. The split between charger, supply, installation and vehicle is usually visible immediately.
Send us a fault to debug