“Uptime” is the number every charging vendor leads with, and the one that hides the most. A single network-wide percentage can look healthy while the sites driving most of your revenue are the ones actually failing. This is a look at the reliability metrics worth tracking instead of - or alongside - the headline number.
Why a single uptime number isn't enough
Two problems sit underneath any quoted uptime figure. First, an average hides distribution: 98% uptime across a network says nothing about whether that 2% of downtime is spread evenly or concentrated at your busiest sites. Second, “available” is a definition, not a fact - a charger reporting as online and idle isn't necessarily a charger that can actually complete a session on request. The metrics below are what closes that gap.
The metrics that actually matter
| Metric | What it tells you |
|---|---|
| Session success rate | The share of session attempts that actually complete without a fault - catches chargers that report “available” but fail when a driver tries to start, which a simple online/offline uptime figure misses entirely. |
| Per-site / per-connector uptime | Uptime broken out by location and connector, not just averaged across the network - the only way to see that downtime is concentrated at a specific high-value site rather than spread evenly. |
| Mean time to detect (MTTD) | How long between a fault occurring and operations being alerted to it. A fault caught by monitoring in minutes costs a fraction of one discovered because a driver complained. |
| Mean time to resolve (MTTR) | How long between detection and the connector being back in service - split out by remote fix vs. truck roll, since the two have very different cost and speed profiles. |
| Remote resolution rate | The share of faults resolved from the operator console - reset, unlock, reconfiguration - without a technician visit. A rising truck-roll rate over time is usually an early signal of aging or poorly maintained hardware. |
| Repeat-fault rate | How often the same connector re-faults after being marked resolved - distinguishes a genuine fix from a temporary workaround, and flags chronic hardware issues before they become a pattern of driver complaints. |
Every one of these ties directly back to revenue - see the hidden cost of EV charging downtime for how to translate an outage into an actual dollar figure, not just a percentage.
What to require from a CSMS to actually track these
- Real-time monitoring at the connector level - status, connectivity and faults, not just a station-level online/offline flag.
- Alerts that open a tracked ticket automatically - so mean time to detect and resolve can actually be measured, not estimated after the fact.
- Remote diagnostics and remote commands - reset, unlock, configuration checks - so a meaningful share of faults never need a truck roll in the first place.
- A full audit trail - every action logged at the request level, so resolution time and remote-vs-onsite split can be reported on, not reconstructed manually.
- Exportable reporting - per-site and per-connector, not just a single network-wide dashboard number.
Turning metrics into action
Set internal targets per metric - not just an overall uptime goal - and review by site rather than only at the network level. A network average can stay flat for months while one site quietly degrades; reviewing per-site MTTD, MTTR and repeat-fault rate is what surfaces that before it shows up as a churned site host or a competitor gaining share at that location. See how CarChargeOS surfaces this level of operational detail on the platform page.
Frequently asked questions
What's a good uptime percentage to target?
There's no single industry-wide benchmark worth anchoring to - what matters more is whether uptime is consistent across sites and connectors, rather than a high average masking a few consistently unreliable locations.
Why track session success rate separately from uptime?
A charger can report as online and available while still failing to actually start a session - a firmware, connectivity or authorization issue that a simple online/offline uptime metric won't catch, but session success rate will.
How do I reduce mean time to resolve without adding technicians?
Increase the remote resolution rate first - a meaningful share of common faults (stuck sessions, configuration drift, unresponsive firmware) can be fixed with a remote command, which resolves the issue faster than dispatching a technician and without the added cost.