A charger that is powered, connected and reporting itself available counts as up. If it fails to start a session for a particular vehicle, or authorises and stops thirty seconds later, the driver experienced an outage the dashboard never recorded.
That gap is why networks with excellent uptime figures collect poor reviews, and why operators are frequently surprised by their own reputation.
What uptime actually measures
In most implementations it measures whether the charger maintained a connection to the backend and reported an available status. Both are properties of the charger's self-assessment rather than of the driver's experience.
A charger has no view of a bay blocked by a non-charging vehicle, a damaged cable, an unreadable display in sunlight, or an approach nobody can park in.
The failures that never generate a ticket
A driver who cannot start a session usually leaves rather than reports. That event exists only in the backend as an authorisation without a subsequent transaction, and only if someone looks for it.
These are the failures that damage utilisation most and appear in operational reporting least, which is a poor combination.
Session success is the honest metric
Attempts that became energy delivered, divided by attempts. It captures everything uptime misses because it measures the outcome the driver came for.
It is harder to compute, because it requires deciding what counts as an attempt, and it is worth the difficulty. A network tracking only uptime is measuring the thing it can influence least.
Silent degradation
Units can report available while operating below capability: a connector that latches unreliably, a contactor slower than it was, a cable with intermittent continuity. None of these produce a fault state.
Detecting them requires trending rather than thresholds, which means retaining history and looking at change over time rather than at current values.
Report both, and explain the gap
Uptime remains useful for contracts and for comparing infrastructure availability. Session success is what predicts whether drivers return.
Reporting both, and treating the divergence between them as the interesting number, is what turns operational data into something that improves the network rather than describing it.
What to change first
- Start recording authorisation attempts that produced no transaction.
- Distinguish vehicle-side stops from charger faults so the two are not conflated.
- Retain status transitions rather than only current state.
- Report session success alongside uptime and watch the gap.