EV Charger Uptime: Measuring, Detecting Faults and Recovering

Unreliable public chargers are one of the most common complaints from EV drivers, and the gap between what operators report and what drivers experience is usually a measurement problem. A charger can be online, reporting Available and answering heartbeats, while every session on it fails. This guide covers how to define and measure uptime, how to spot faults from OCPP data, what you can fix remotely, and how to organize field work.

Define what up means

There are three useful definitions, and they give very different numbers:

• Connectivity uptime: the station has an open OCPP connection. Easy to measure, and the least meaningful.
• Status uptime: the connector reports a usable status (Available, Preparing, Charging and so on) rather than Faulted or Unavailable. Better, but it trusts the charger's self-assessment.
• Functional uptime: the port can actually deliver energy at the expected power. The only definition drivers care about, and the hardest to measure.

The US NEVI rule uses a functional definition: a port is up when hardware and software are online and available or in use, and it can deliver at least the minimum power level. Uptime is calculated per port as ((525,600 - (T_outage - T_excluded)) / 525,600) x 100 over the previous twelve months, with specific exclusions such as utility outages and scheduled maintenance. Even if you are not NEVI-funded, it is a reasonable model. See NEVI and AFIR requirements.

Measure at the port, with causes

Uptime must be per port (connector or EVSE), not per station. A dual-port charger with one dead connector is half-down. Store outages as intervals with a start, end, port, detection source and cause category, rather than computing uptime from status snapshots. That gives you the T_outage and T_excluded numbers regulators want, and it gives operations a work queue.

Pair uptime with a session success rate: of the sessions where a driver tried to charge, how many delivered meaningful energy? Define meaningful explicitly (for example, a minimum kWh or duration) and track failures by charger model, firmware version, site and vehicle make where you have it. A port with good uptime and poor session success has a problem your status data is not showing.

Detecting faults from OCPP data

Explicit signals

The charger reports problems through StatusNotification. In OCPP 1.6 a fault looks like this:

[2, "81c2", "StatusNotification", {
  "connectorId": 2,
  "status": "Faulted",
  "errorCode": "GroundFailure",
  "vendorErrorCode": "E-217",
  "timestamp": "2026-10-26T08:14:03Z"
}]

errorCode gives you a standard category; vendorErrorCode and info carry the detail, and you will need a per-vendor mapping to make them actionable. Note that a non-fatal error can arrive with a status other than Faulted. In 2.0.1, connector status and error reporting are separated: StatusNotification carries the connector status, and problems surface through NotifyEvent and device model monitoring. See the status notification post and the 2.0.1 device model.

Implicit signals

Many failures never produce a fault status. Build detectors for patterns like these:

• Silent disconnection: no heartbeat or other message for several heartbeat intervals.
• Authorized but never started: Authorize accepted, connector moves to Preparing, then back to Available with no transaction. Often a cable, contactor or vehicle communication issue.
• Zero or near-zero energy sessions: a transaction starts and stops with almost no energy delivered.
• Low power delivery: sessions consistently far below the rated power for vehicles that can accept more, which can indicate failed power modules on DC chargers.
• Stale meter values: MeterValues stop arriving mid-session or the register does not advance.
• Reboot loops: repeated BootNotification messages in a short period.
• Stuck states: connector in Finishing or SuspendedEVSE for an abnormal time.

Combine these into a per-port health state and alert on transitions, not on every message. A single failed session is noise; three in a row on the same port across different vehicles is a fault.

Remote recovery

A large share of faults can be cleared without a site visit. OCPP gives you the tools:

Automate the safe steps. A common escalation is: trigger a status, wait, soft reset if still faulted, wait, hard reset, then take the port out of service and open a field ticket. Never reset a charger with an active session on another port unless you have to, and rate-limit automatic resets so a broken unit does not reboot all day. The firmware and diagnostics post and troubleshooting guide cover the details.

Marking a known-bad port Inoperative is itself a reliability measure: it updates OCPI status for roaming apps, so drivers are not sent to a charger that will fail.

Field operations

• Tickets from detectors: open work orders automatically from health state changes, with the evidence attached: last messages, error codes, failed sessions.
• Remote first: require the remote recovery steps to have run before a truck roll is scheduled.
• Parts and skills: classify faults so the right technician arrives with the right part. A DC power module fault and a broken screen need different visits.
• Close the loop: record the root cause and fix, and feed it back into the detector and vendor mapping. Track repeat failures per model and firmware version.
• Vendor accountability: keep per-model failure data. It is your strongest input to warranty claims and hardware selection.

Key takeaways

• Measure functional uptime per port, with outage intervals and causes, plus session success rate.
• Explicit fault statuses catch only part of the problem; build detectors for silent failures.
• Automate a safe remote recovery ladder and make it a precondition for site visits.

HashTech builds monitoring and remote recovery into the CSMS platforms we deliver; AI-based failure prediction is covered in our AI enablement work.