Otto is GridLink's autonomous operator for EV charging.
A charger that works is a stack of systems working: the charger, its network connection, the CMS running sessions and payments, and the vehicle. Otto reads all of them together and names what actually failed. Then it runs the repair. Resets, retries, and configuration changes go out automatically and get verified, so the fault clears without a site visit.
One fault pattern, as Otto runs it. This trace: 39 seconds, fault message to verified session.
EV charger troubleshooting, running automatically.
Four failure modes account for most of what empties a charger without ever taking it offline. Each one is visible in the data long before a driver calls it in, and each one turns into a maintenance ticket if nobody catches it. Here is what each looks like, and what Otto does with it.
Stuck connectors
connector 2 · locked 00:11:38
A session ends and the cable stays locked, so the next driver cannot plug in and the current one cannot leave. Otto sends the unlock and confirms the connector actually let go.
Payment timeouts
timeout at 00:00:30 · session never started
The charger waits on an authorization that never comes back, and the session dies before it starts. Otto catches the failed handshake and retries the start while the driver is still standing there.
Derating
Status still reporting Charging.
The unit reports healthy while delivering a fraction of what it should. Otto compares delivered power against the rating and surfaces the gap instead of letting it hide behind a green status.
Offline chargers
last heartbeat 00:04:12 ago
The charger stops answering and the unit stops reporting. No software reaches a charger that has gone quiet, so Otto works out what dropped, the unit, the site connection, or the backend, and takes it to whoever can act on it.
Three ways a fault closes, and only one of them is a site visit.
Most reliability software stops at the edge of what it can reach over the wire and hands you everything else. Otto tries all three in order, so the question is never whether a charger is reachable by software, only who is closest to the fix.
Cleared remotely
Resets, retries, and configuration changes run through the management system you already have. The charger is checked before the ticket closes.
Nobody involved
Cleared by whoever is already there
When the fix is physical but simple, GridLink texts the person who reported it and walks them through it, step by step, any hour. This works on chargers with no network connection at all.
Breaker back on, GFCI reset, unit powered up
Dispatched, already diagnosed
When it genuinely needs parts or hands, the ticket carries the cause, the evidence behind it, and the part when there is one. Your technician starts at the fix.
One visit, not a diagnostic trip
Which conversations run is set by your team and approved in advance. Anything outside them goes to a person, and every message and action is written back where your team already works.
The automated fixes run through the management system you already have, on the hardware you already own. Nothing gets installed on a charger and nothing gets replaced.
Every fault, the stage it is at, and what Otto did about it.
Each station carries its own trace: the messages that raised the fault, the classification, the command Otto sent, and the confirmation that the charger came back.
- EVSE-0421 Connector locked after session end resolveRunning fix
- EVSE-0117 Charger offline diagnoseSite link down
- EVSE-0308 Payment authorization timeout resolveCleared
- EVSE-0562 Delivering below rated power diagnoseReading power samples
- EVSE-0894 Charger offline escalateSite visit queued
Resolution trace EVSE-0421
- 02:14:06 StatusNotification Faulted · connector 2
- 02:14:07 Fault classified Connector lock not released
- 02:14:09 UnlockConnector Sent through CMS API
- 02:14:22 StatusNotification Available · connector 2
- 02:14:22 Verified Connector released, charger back in service
The questions operators ask first
Resets, retries, unlocks, and configuration changes, run through the management system you already use and verified before the ticket closes. Beyond that, when the fix is physical but simple, Otto texts the person who reported the fault and walks them through it, which reaches faults no command can: a tripped breaker, a GFCI, a unit with no network connection at all.
You do, in advance. Otto runs the actions and the conversations your team has defined and approved, and nothing else. Anything outside that set goes to a person instead, and every message it sent and every action it took is written back where your team already works, so it can be reviewed after the fact.
When you want it to. Someone standing at a charger that will not start can reach Otto by text and get a real answer in seconds rather than a queue, including whether the bay next to them is working. If it cannot resolve the conversation it hands a person the whole thread, so the driver is not asked the same twenty questions again.
The automated fixes need an API to act through, so on those units Otto does not run them. The diagnosis, the guided walkthrough, and the escalation with evidence all still work, which is most of what closes a fault at a site with someone on it.
It tries what it can first and checks whether the charger came back. It escalates when the evidence points at damage or a part, when the guided steps did not clear it, or when it is not confident enough to act. A low-confidence escalation carries what it checked and what it ruled out rather than a guess.
The rest of the common questions, on integration, NEVI, and building this in-house, are answered on the homepage. What this looks like for a specific operation is covered on public networks, fleets, OEMs, and site hosts.
See Otto run against your own faults.
We will walk your network's failure patterns, show what clears remotely, and where Otto would have saved the site visit. The reliability calculator puts a number on it first if you would rather start there.