When the Backend Goes Down, Do Your Chargers Go Dark? What EV Charger Owners Really Mean by OCPP Endpoint Fallback

Picture a Monday at 6 a.m. Nothing is wrong at any of your sites. The chargers are powered, the 4G links are up, the cables are fine. But an overnight change to the charging platform’s server, or an expired certificate, or a cloud region having a bad hour, means every charger fails to connect. Your dashboard shows a wall of red. Drivers arrive and nothing starts.

When an owner asks us for "OCPP endpoint fallback", this is the scene they are describing. They want a second address a charger can connect to when the first one is gone, so that a single backend problem does not take every site offline at once.

It sounds like one feature. It is actually three different problems, and the first step is to separate them.

Three things people call "fallback"

	What failed	Who is affected	Where it is covered
Site uplink loss	The charger cannot reach the internet	One site	Our post on OCPP 1.6J offline behaviour and local CSMS proxies
Backend or endpoint outage	The charger can reach the internet but the CSMS address does not answer correctly	Every charger pointed at it	This post
Provider change	You want to move to another CSMS, or run two side by side	Whole network	Touched on below

Most owners lump these together because the symptom is the same: red dots. The fixes are not the same.

The pain points owners describe

These are the themes we hear, in roughly this order.

One address, one point of failure. Every charger has a single CSMS URL. If that address stops working, there is nothing else for the charger to try.

Nobody is on site. The charger firmware may only accept a new URL from the very system that is down. Fixing it can mean a technician visiting each site, or a vendor portal that only the charger manufacturer controls.

Lost or messy billing records. Sessions that run during an outage have to be buffered by the charger and delivered later. If the backend then comes back with different rules, or a different transaction numbering, sessions can be duplicated or go missing.

Payments stall. Drivers who pay by QR code and PromptPay or QR30 need the backend to confirm payment. If the backend is gone, those sessions cannot start, however good the charger is.

Lock-in. A charger tied to one vendor’s backend leaves the owner with no practical way to leave, or to test another platform on a few chargers first.

Reconnection storms. When a backend returns, hundreds of chargers try to reconnect at the same moment, and the recovering system falls over again.

Why this is hard in OCPP

OCPP is a protocol between a charger and one CSMS. It says what the two sides say to each other once connected. It says much less about which address a charger should try, and in what order.

OCPP 1.6J. To our knowledge the specification does not define a list of backup endpoints. The CSMS address lives in the charger’s own configuration, usually under a vendor-specific setting. Whether a second address is supported at all depends on the firmware. The Open Charge Alliance’s own guide to improving uptime covers offline behaviour in detail but does not cover multiple backend URLs or CSMS failover.

OCPP 2.0.1. This version adds a way to store connection profiles on the charger. A CSMS can send a SetNetworkProfile message that places a connection profile, including the CSMS address and security profile, into a numbered configuration slot on the charger. The standard also has a use case for migrating a charger to a new CSMS. That gives a charger more than one place to go, but how it chooses between them and when it switches is something to confirm with the vendor. Many chargers in the field, including in Thailand, are still on 1.6J, so the 2.0.1 route is not something to count on today.

The practical conclusion is that for most installed chargers, fallback has to be built around the charger, not inside the protocol.

Four layers where fallback can live

flowchart TD
    A["Charger"] --> B["Layer 1 Charger firmware backup URL"]
    A --> C["Layer 2 One stable hostname"]
    C --> D["Primary CSMS"]
    C --> E["Standby CSMS"]
    A --> F["Layer 3 Local proxy at the site"]
    F --> C
    A --> G["Layer 4 Charger offline mode"]

Layer 1: a backup URL in the charger. If the firmware supports a second endpoint, use it. It is the simplest answer and entirely the vendor’s feature. Ask before you buy, and test it before you rely on it.

Layer 2: one stable hostname, with the failover behind it. The charger is pointed at a single name you control. Behind that name, DNS or a load balancer sends the connection to a healthy backend, and a standby can take over without anyone touching a charger. This works with chargers that only know one URL. The cost is that you now own the name, the certificate and the health checks.

Layer 3: a local proxy at the site. A small service on the site network keeps the charger talking to something nearby, buffers messages, and forwards them when the backend is reachable. It can also hold the list of backends. It helps most at remote or high-value sites, and it adds a component to patch and monitor, so it is a per-site decision.

Layer 4: the charger’s own offline mode. If everything else fails, the charger should still let known drivers charge and queue the records. This is the last line, not a substitute for the others.

What fallback does not fix

Be wary of anyone who says it is just a second URL.

• Both backends must know the same things. A standby that does not have the same charger list, RFID list, tariffs and credentials will reject the charger or bill it wrongly.
• Never two active brains for one charger. If two backends both think they own the same charger, you get duplicate transaction numbers and conflicting commands. Decide which is active and how a handover is declared.
• Certificates and credentials follow the charger. A standby needs a valid certificate for the name the charger expects, and must accept the same charger identity and password or certificate.
• Reconnection needs pacing. For OCPP 2.0.1 chargers, the Open Charge Alliance suggests tuning the back-off settings, with a small minimum wait and a wide random range, so the fleet does not return all at once.
• Payments are a separate dependency. QR and PromptPay sessions depend on the payment confirmation path, not only on OCPP.
• Unknown-driver offline charging has a cost. Letting anyone charge while offline is a risk you carry. The OCA’s guide notes it is often acceptable on AC chargers and often too risky on DC fast chargers.

Questions to ask your charger vendor and your CSMS provider

Question	Why it matters
Does the firmware accept a second CSMS URL, and how does it choose?	Decides whether Layer 1 exists
Can the URL be changed remotely, or only on site?	Decides the cost of a failed backend
Which OCPP version, and is SetNetworkProfile supported on 2.0.1?	Decides your options
How long does the charger keep and replay queued transactions?	Protects billing records
What are the back-off settings after a failed connection?	Avoids reconnection storms
Can the charger use a hostname you control, with TLS?	Makes Layer 2 possible
Can a standby CSMS import the same charger, tag and tariff data?	Makes the standby real
Has failover been tested with this exact model?	The only proof that counts

What we offer today, and what is project work

We are careful to separate the two.

Part of the platform today: an OCPP 1.6J engine, OCPP 2.0.1 as an upgrade path, managed hosting with backups and restore drills, uptime monitoring and an on-call rotation, and the option of a local CSMS proxy for unreliable sites.

Scoped per project, not an out-of-the-box switch: a stable hostname and failover design in front of your backend, a standby arrangement and the data sync it needs, a back-off and reconnection review for your fleet, and a failover test at commissioning for each charger model you operate.

What we cannot promise: that every charger model supports a backup URL. That is firmware, and it differs by vendor. We confirm it by testing, not by reading a datasheet.

If you operate chargers today and want to know how exposed you are, send us your charger brands and models, the OCPP version, how the CSMS address is set, and how many sites to hello@simplico.net with the subject "OCPP fallback review". We reply with a scoped outline within 48 hours. You can also reach us on LINE at iiitum1984.

FAQ

Can I just add a second URL to every charger?
Only if the firmware supports it. On OCPP 1.6J there is no standard backup list, so many chargers accept just one address. A stable hostname with failover behind it is the usual workaround.

Does OCPP 2.0.1 solve this?
It helps. It lets a charger hold more than one connection profile, but you still need to confirm how your chargers choose between them. Many installed chargers are on 1.6J today.

What happens to a session that is running when the backend goes down?
A charger normally keeps an authorized session going and queues the messages for later. What it does for new sessions depends on its offline settings and on how the driver pays.

Will fallback protect QR and PromptPay payments?
Not by itself. Those sessions depend on payment confirmation, so plan them as connectivity-dependent.

Is a local proxy the same as a backup CSMS?
No. A proxy buffers and forwards for one site. A backup CSMS is a second central system that can take over for the whole fleet. Some designs use both.

Do you need to change my chargers?
Often not. The most common design leaves the chargers alone and changes what sits behind the address they already use.

Who is behind this?
Simplico, a software engineering studio based in Thailand. We build and operate EV charging platforms for operators across Thailand and Southeast Asia.

Related Posts

• What an EV Charger Does When the Internet Drops: OCPP 1.6J Offline Behaviour and Where a Local CSMS Proxy Fits
• How to Build an EV Charging Network Using OCPP: Architecture, Technology Stack and Cost Breakdown
• Scoping an EV Charging Platform for a Large Property Owner
• Simplico EV charging platform (CSMS)
• Improving uptime with OCPP, Open Charge Alliance