Every charge point operator has lived this moment: a driver tweets a photo of a dead charger, support pulls up the dashboard, and the dashboard says everything is fine.
Public charging reliability is now a regulated topic in the UK — the Public Charge Point Regulations 2023 set a 99% reliability requirement for rapid networks — and it's a scored line in almost every tender. Yet "is this charger actually working?" remains a surprisingly hard engineering question.
Here's a field guide to how chargers really fail, and what monitoring catches each mode.
Failure mode 1: the connectivity drop
The most common "offline" charger is a charger that's working perfectly — and unreachable. Cellular backhaul in a metal cabinet at the edge of a car park is a hostile radio environment: SIM contract lapses, roaming fallbacks, congested cells, antenna damage, a router that needs a power cycle.
What catches it: heartbeat monitoring with a tight, per-charger baseline. A charger that heartbeats every 300 seconds and has missed two beats is a signal; waiting for a human to notice a grey icon is not. Track reconnection quality too — a charger that drops and recovers forty times a day is a site problem waiting to become a hard failure.
Failure mode 2: online but unusable
The charger is connected, heartbeating, and green on the map — and every session attempt fails. Causes we see repeatedly: a connector stuck in Faulted after a ground-fault trip, a payment terminal that crashed while the OCPP side stayed up, a cable-lock actuator that no longer releases, RFID readers that stopped reading.
This is the failure mode that destroys driver trust, because the network advertises the charger as available.
What catches it: don't monitor connectivity — monitor outcomes. Session success rate per charger over a rolling window is the single most honest health metric a network has. A charger with five consecutive failed session starts is broken, whatever its status message says.
Failure mode 3: the stuck or half-applied update
Firmware and configuration changes are a leading cause of self-inflicted downtime: an update that downloads but never applies, applies but bricks the payment module, or applies cleanly and resets a critical setting to a vendor default.
What catches it: per-device rollout telemetry — downloaded, applied, failed, with error codes — and rollouts that are staged so a bad update hits a canary cohort of ten chargers, not a fleet of a thousand. We've written up our approach in Safe, staged firmware rollouts at scale; the short version is that automatic rollback thresholds turn "bad firmware weekend" into a non-event.
Failure mode 4: zombie sessions and stuck state machines
A car left overnight on a completed session, a StopTransaction that never arrived because connectivity blipped at exactly the wrong moment, an EVSE state machine wedged between Finishing and Available. The connector is physically fine but logically occupied — invisible lost revenue.
What catches it: session duration anomaly detection (a 14-hour AC session at a rapid hub is not a charging session, it's a stuck one) and reconciliation between meter values and transaction state. This class of fault is where pattern-learning systems genuinely earn their keep — our Cortex models flag connectors whose behaviour has drifted from their own historical baseline, which surfaces wedged state machines that no threshold rule would define in advance.
Failure mode 5: the slow physical death
Connector wear, cable damage, cooling-fan failure in DC units, water ingress. These rarely fail suddenly — they degrade: error rates creep, sessions terminate early more often, delivered power sags below the rated maximum.
What catches it: trend analysis on error codes and delivered-power ratios per connector. A connector whose early-termination rate has doubled over three weeks deserves a maintenance visit before it becomes a hard fault and a driver complaint. This is textbook predictive maintenance territory — the economics of catching these early are covered in our piece on predictive maintenance.
Putting it together: monitoring that mirrors reality
The pattern across all five modes: no single signal defines "working". A defensible uptime picture layers four things:
| Layer | Question it answers | Typical signal | |---|---|---| | Connectivity | Can we reach it? | Heartbeats, WebSocket state | | Protocol health | Is it behaving? | Status notifications, error codes | | Outcomes | Can drivers charge? | Session success rate, delivered kWh | | Trends | Is it degrading? | Baselines, anomaly scores |
If your reporting stops at the first layer, your dashboard will keep telling you everything is fine while a driver photographs the evidence to the contrary.
One more thing: whatever you measure, publish it. Reliability claims carry far more weight in tenders when they're backed by continuously collected evidence rather than a quoted figure — it's why we publish per-service latency and availability from our own load tests on our performance page.
AmpNexus tracks connector-level availability, session outcomes and behavioural baselines across mixed-vendor fleets — see the Portal and Cortex AI.