Ask five charge point operators what their uptime is and you will get five numbers, all above 97%, none of them comparable. The figure has become a piece of marketing rather than a measurement, which is a problem for everyone: for landlords who write it into contracts, for lenders who underwrite against it, and most of all for drivers, whose experience of a network is roughly the inverse of it.
The confusion is not dishonesty. It is that "uptime" for a charger has at least three defensible definitions, and operators naturally reach for the flattering one.
Three definitions, three very different numbers
Consider a single DC charger over a 30-day month. It was disconnected from the network for 6 hours after a fibre cut. Its CCS gun was reporting a fault for 40 hours before a technician replaced the cable. And for 14 hours it was fine but the bay was blocked by a diesel car.
| Definition | What it measures | Result |
|---|---|---|
| Connectivity uptime | Charger was talking to the platform | 99.2% |
| Availability uptime | A connector was able to start a session | 93.6% |
| Serviceable uptime | A driver could actually have charged | 91.6% |
All three numbers are true. Only one of them describes what a driver experienced. And the gap between the first and the third — nearly eight percentage points on one unit in one month — is exactly the gap between a network that is trusted and one that is not.
Why connectivity is the wrong proxy
Connectivity is the easiest thing to measure, which is why it is the most commonly quoted. Heartbeats arrive; the charger is up. But a charger can heartbeat happily for days with a faulted connector, a seized cable latch, or a payment terminal that rejects every card. From the platform’s point of view the unit is healthy. From the kerb it is a brick.
The counterpart failure is just as common: a charger that is offline but perfectly capable of charging, because it holds a local authorisation list and buffers transactions. Counting that as downtime penalises a unit that served drivers without interruption.
What a defensible calculation looks like
Uptime should be derived from the connector state timeline that OCPP already gives you. Every StatusNotification is a state transition with a timestamp; the sequence of those transitions over a period is the raw material. You do not need a separate monitoring system, you need to stop throwing the transitions away.
- 01Take every connector state transition in the period: Available, Preparing, Charging, SuspendedEV, SuspendedEVSE, Finishing, Reserved, Unavailable, Faulted.
- 02Classify each state as serviceable or not. Available, Preparing, Charging, SuspendedEV and Finishing are serviceable — a driver is being served or could be. Faulted and Unavailable are not.
- 03Treat platform disconnection as unserviceable only if the charger cannot authorise locally. If it holds a local list and buffers transactions, it was serving drivers.
- 04Subtract declared maintenance windows from the denominator, not from the numerator. A planned outage is excluded time, not uptime.
- 05Aggregate connector-seconds, not charger-days. Weighting by connector is what makes multi-gun sites comparable to single-gun ones.
The result is a number in the low-to-mid nineties for most real networks, which feels uncomfortable to publish until you realise that everyone quoting 99.5% is measuring the first definition. The operators who win contracts are increasingly the ones who quote the honest number and attach the outage list.
The outage list is the actual deliverable
A percentage is an argument; an outage list is evidence. For each outage, a landlord or a lender wants five fields: which connector, when it started, when it ended, what the fault code was, and what you did about it. If you can produce that table on demand, the percentage almost stops mattering — you have demonstrated that you are measuring at all, which puts you ahead of most of the market.
It also changes internal behaviour. Once every outage has a cause attached, patterns appear within a month: one model whose contactor sticks in humidity, one site whose connectivity dies every afternoon, one firmware version that stops reporting meter values. None of those are visible in an aggregate percentage.
Setting a target you can actually hit
For a mixed AC and DC network in India, serviceable uptime in the range of 95–97% is a realistic operating target, and getting there is mostly unglamorous: SIM redundancy, a spare-cable stock at the depot rather than in a warehouse, a firmware baseline you actually enforce, and a fault triage habit that pulls diagnostics before dispatching a van.
Above 97% the constraint stops being your process and starts being your hardware choices and your grid connection. That is a procurement conversation, not an operations one — but at least by then you will know which of the two is costing you.