If you run a charging network, you probably know the feeling: the dashboard says everything is fine, but a driver messages to say the charger wouldn’t start. That gap between what your system reports and what a driver experiences is where reliability is really decided. For many operators, uptime is the number they watch. It tells you how often a charger is available over time:

Uptime = (total hours − downtime hours) ÷ total hours × 100

At 99% uptime, a charger is out of service for about 3.6 days a year. At 97%, it’s about 11 days. Those are useful numbers for maintenance planning and contracts. But drivers don’t experience your network in hours. They experience it in attempts. A charger can be “online” for most of the month and still fail a meaningful share of the people who plug into it.

This article looks at why that gap matters, what first‑time charge success rate (FTCSR) actually measures, and how you can start using it to make better decisions across your network.

TL;DR

• Uptime measures whether a charger is reachable; first‑time charge success rate (FTCSR) measures whether a driver’s first plug‑in delivers energy without a retry.
• The gap is real: independent studies put first‑attempt success between about 71% and 86% on networks reporting around 99% uptime.
• Most first‑attempt failures happen before energy flows at authorisation or during the vehicle charger handshake. A status of “Available” says nothing about either.
• Measuring FTCSR means logging attempts that never become transactions, linking retries into one driver attempt, and normalising error codes.
• Segment the rate by charger model, firmware version, vehicle make, authorisation method and roaming partner. That’s where it becomes an operating tool.
• Contracts are still written around uptime. Drivers, roaming partners and site hosts increasingly judge on success.

Uptime is a time weighted measure of the asset. A charger that reports “Available” through an OCPP status notification counts as up, whether or not the next session works. Many uptime calculations also exclude scheduled maintenance, grid outages and causes outside the operator’s control. That’s reasonable for a contract but it isn’t how a driver experiences your site.

FTCSR is an attempt‑weighted measure of the outcome. It asks a narrower question: when a driver plugs in for the first time on a visit, does energy start flowing without a retry, a call to support, or a move to the next bay. The two diverge for three reasons, and each one compounds. Uptime tells you whether you met the contract. FTCSR tells you whether you kept the customer.

What first‑time charge success rate measures, and what the alternatives hide

While there isn’t a global definition to charge success yet, the industry is converging. A US national‑lab consortium has defined charge start success, charge ending success and session success as near‑term KPIs, with further work moving to a standards body. In Germany, a new charging success rate splits the outcome into an authentication success rate and a transaction success rate. A practical working definition for a CPO has the following formula:

FTCSR = first attempts per visit that deliver energy above a minimum threshold, with no driver retry or manual intervention ÷ all first attempts per visit.

What it takes to measure FTCSR from your CSMS

Most CSMS reporting is built around transactions, and FTCSR lives partly outside them. An attempt that fails at authorisation never opens a transaction, so it never reaches the report. The data is often there; the model is not. It might be time to rework your reliability reporting if:

• You can report uptime per charger but not the count of rejected authorisations per charger.
• A driver who tries three times appears as three sessions, or as none.
• Error codes arrive in each hardware vendor’s own format and are compared by hand.
• You cannot split success by vehicle make, firmware version or eMSP.

The building blocks are specific. Capture authorisation requests and rejections, plug‑in events without a start, and stop reasons. OCPP 1.6 carries these across Authorize, Status Notification and Stop Transaction; OCPP 2.0.1 consolidates much of it in Transaction Event, with trigger and stopped reasons. Link events by connector, ID token and a short time window, so a retry isn’t counted as a fresh first attempt. And decide what counts as delivered energy (a minimum kWh or duration) and hold that definition steady so trends mean something.

‍
If your network reported its first‑time charge success rate tomorrow, would you know the number and would you know which chargers, vehicles and partners sit behind it? We regularly work through this question with CPOs across Asia. If it’s on your list, Eigen Digital is happy to compare notes. Connect with us for a demo.

FAQ

Q: What is first‑time charge success rate?
It is the share of first plug‑in attempts on a visit that deliver energy without the driver retrying, calling support or moving to another charger. It measures the driver’s outcome, where uptime measures the charger’s availability.

Q: What is the difference between charger uptime and charge success rate?
Uptime is time weighted: the share of hours a charger is reachable and not faulted. Charge success rate is attempt‑weighted: the share of sessions that actually work. A charger can show high uptime while failing many sessions at authorisation or at the vehicle handshake.

Q: What is a good first‑time charge success rate for public DC charging?
There is no regulated target yet. Independent studies put recent averages between about 71% and 86%. A rising trend by charger model matters more than any single headline figure.

Q: How do you calculate charge success rate with OCPP?
Combine authorisation, status and transaction events per connector, stitch retries by the same ID token within a short window into one attempt, and apply a minimum energy or duration threshold. OCPP 1.6 spreads these across several messages; OCPP 2.0.1 consolidates much of it in transaction event.

Q: Why do EV charging sessions fail to start?
Most start failures happen before energy flows: authorisation problems such as unsynchronised tokens, timeouts or roaming lookups; vehicle charger communication errors, often after firmware updates; and physical issues such as connector locking faults.