Services / Network Audit

EV Charging Network Technical Audit

Reported uptime and experienced reliability are different numbers, and the gap between them is where charging networks lose customers without knowing why.

A charger that is powered, connected and reporting available will count as up. If it fails to start a session for a particular vehicle, or authorises and then stops after thirty seconds, the driver experienced an outage that the dashboard did not record.

Request the checklist

For CPO, investor, network owner

01

What an audit examines

Swipe to compare

AreaWhat it reveals
Session success rateAttempts that did not become energy delivered, which uptime hides
Failure distributionWhether faults concentrate in sites, hardware revisions or firmware builds
Firmware driftHow many distinct builds are actually deployed across the fleet
ConnectivitySites where the backend link is marginal rather than absent
Transaction integritySessions lost or unbilled after connection interruptions
Silent faultsUnits degraded but still reporting available
Ticket flowFaults resolved without a recorded root cause, so they recur
02

Session success is the honest metric

Uptime measures the charger's opinion of itself. Session success measures whether drivers got energy. Networks that track only the first are frequently surprised by their own review scores.

03

Firmware drift is usually worse than expected

Fleets accumulate builds. Units that were offline during a rollout, replaced under warranty, or commissioned from old stock end up on versions nobody is tracking. That makes fault patterns unreadable, because the same symptom has different causes on different builds.

Establishing the actual version distribution is often the single most useful output of an audit.

04

Faults that never generate a ticket

A driver who cannot start a session usually leaves rather than reports. That failure exists only in the backend logs, as an authorisation without a transaction, and only if someone looks. These are the failures that damage utilisation most and appear in operations reporting least.

05

What the audit produces

  • Session success rate against reported uptime, and the gap explained
  • Failure concentration by site, hardware revision and firmware build
  • The actual firmware version distribution across the fleet
  • A ranked list of remediation actions by sessions recovered
  • The faults recurring because no root cause was recorded
06

Vendor-independent

The audit runs against whatever hardware and platform the network uses. Where the finding is that a particular vendor's units underperform, that is the finding, and RIOD supplying alternatives does not change the analysis. You should still weigh it knowing we sell chargers.

07

What an audit should look for that operators rarely check

Network audits usually report uptime, session success and fault counts. Useful, and all of it describes what has already happened.

The findings that change decisions are the structural ones. The first is platform portability: if the fleet cannot change management platform remotely, the operator has an unpriced liability. We know its size because we paid it, sending people to every charger in the field to deploy a change that could not be made any other way on a shared platform.

The second finding is what the fault counts actually contain. An operator who has not separated these is managing a hardware problem they may not have.

  • Unit failures, which is what a warranty covers. Ours run near 0.5 percent, about one charger in two hundred
  • Supply and installation faults, which look identical in a fault log and belong to a different contractor entirely
  • Vehicle side behaviour, which no amount of charger replacement will fix

Want this applied to your own site?

Request the checklist

Technically reviewed by Akhil Joy, CEO. Last reviewed 2026-08-29.

Frequently asked questions

Our uptime is high. Why audit?

Uptime measures the charger's opinion of itself. Session success measures whether drivers got energy. The gap between them is where networks lose customers without a ticket ever being raised.

What do you need access to?

Backend session and transaction records, fault logs, and the firmware version inventory if one exists. Where it does not, establishing it is usually the most useful early output.

Can you audit a network built on other vendors' hardware?

Yes, and most are. The analysis is vendor independent, though you should weigh our findings knowing we also sell chargers.

Why does firmware drift matter?

Because fault patterns become unreadable when the same symptom has different causes on different builds, and fleets accumulate builds through warranty replacement and offline units missing rollouts.

What is the most common surprising finding?

The number of authorisation attempts that never became a transaction. Those drivers left rather than reported.

Request the technical audit checklist

The checks we run, written to be used against any vendor's hardware and any platform, including ours. Ask and we will email it to you.

Request the checklist