Maintenance usually gets budgeted as a hardware line item - a service contract, a technician rate - but the thing that actually determines how much maintenance costs, and how fast a connector comes back online, is the triage process sitting between a fault and a truck roll. This is a guide to running that process, not a hardware maintenance schedule.
Three tiers of response, not one
Every fault a charger reports falls into one of three response tiers, and the split between them - more than anything about the hardware itself - is what determines cost and mean time to resolve:
| Tier | Examples | Typical resolution path |
|---|---|---|
| Preventive | Firmware updates, scheduled connector and cable inspection, cleaning | Scheduled, before a fault occurs |
| Remote-resolvable | Stuck sessions, configuration drift, unresponsive firmware, minor connectivity blips | Reset, unlock or reconfigure from the operator console - no site visit |
| Onsite-required | Physical cable or connector damage, persistent hardware faults, electrical issues | Technician dispatch |
The goal of a maintenance program isn't eliminating faults - hardware fails regardless of process. It's maximizing the share that resolve in the first two tiers before they ever require the third, since a truck roll is the slowest and most expensive path by a wide margin.
What a remote-first triage process actually looks like
- A fault is detected and a ticket opens automatically. The gap between a fault occurring and operations finding out about it - mean time to detect - should be minutes, not the next time someone checks a dashboard or a driver complains.
- The fault is diagnosed from the message stream, not guessed at. A connector reporting Faulted, a session stuck without a StopTransaction, or MeterValues that stopped updating each point to a different root cause - see the OCPP messages glossary for what the most common fault signals actually mean.
- A remote fix is attempted first. Reset, unlock the connector, or push a configuration check - resolved in minutes if it works, and costs nothing if it doesn't beyond the attempt itself.
- Only unresolved faults escalate to dispatch. By the time a technician is sent, the fault type, diagnostic history and any remote attempts already made should travel with the ticket, so the visit starts with a known problem instead of a cold diagnosis onsite.
Preventive maintenance: the part that's easy to skip
Preventive maintenance doesn't show up as an emergency the way a broken connector does, which is exactly why it's the first thing cut under budget pressure - and usually the most expensive place to cut. A few practices worth building into a recurring schedule rather than reacting to:
- Firmware currency. Chargers running outdated firmware both miss vendor-issued bug fixes and, over time, drift out of full compatibility with newer OCPP features - see OCPP 1.6 vs. OCPP 2.0.1 for what a protocol-version gap can mean in practice.
- Physical inspection of cables and connectors. The parts that fail from ordinary wear and tear - not a controller fault a remote reset can fix - and the ones a purely software-side monitoring setup will never catch on its own.
- Reviewing repeat-fault history, not just open tickets. A connector that keeps re-faulting after being marked resolved is flagging a hardware issue that a remote fix is only patching over, not solving.
In-house team or a service contract?
Neither is universally right - the decision usually comes down to network size and geographic spread. A small, concentrated network can often justify an in-house technician once remote resolution is handling most faults. A network spread across many sites and regions more often makes sense with a service contract - the hardware vendor's own network, or a third-party field service provider - since building an in-house onsite presence in every market a network operates in rarely pencils out below a certain scale. Either way, the remote-first triage process above is what determines how often that contract actually gets used, which is usually the bigger lever on total maintenance cost than the per-visit rate itself.
What to require from a CSMS to run this well
- Connector-level monitoring, not station-level. Status, connectivity and faults visible per connector, since averaging across a multi-connector station hides exactly the problem this process exists to catch.
- Alerts that open a tracked ticket automatically. Without this, mean time to detect and resolve can't actually be measured - only estimated after the fact.
- Remote commands built into the console. Reset, unlock and configuration checks available directly to operations, not routed through the hardware vendor's own separate tool.
- A full audit trail per ticket. What was tried remotely, when, and by whom - so a technician dispatched after a failed remote fix isn't starting the diagnosis over.
This is what turns maintenance from a reactive cost center into a measurable process - see the reliability metrics worth tracking once the triage process above is in place, and the hidden cost of downtime for why the remote-vs-onsite split matters as much financially as it does operationally. See how CarChargeOS handles monitoring, alerting and remote operations on the platform page.
Frequently asked questions
What share of faults should resolve remotely, without a truck roll?
There's no single benchmark worth anchoring to - it depends heavily on hardware age and mix - but a rising truck-roll rate over time, rather than the absolute number at any point, is the signal worth watching. It usually points to aging hardware or a triage process that's escalating faults a remote fix could have caught.
Is preventive maintenance worth it if remote monitoring already catches faults fast?
Yes - remote monitoring catches faults after they happen. Preventive maintenance, particularly physical inspection and firmware currency, is what prevents some of those faults from occurring in the first place, which is always cheaper than even the fastest remote fix.
Do I need an in-house maintenance team to run a reliable network?
No - a service contract with the hardware vendor or a third-party field provider works for most networks, especially ones spread across multiple sites or regions. What matters more than who performs the onsite visit is how much gets resolved before a visit is ever needed.