Will your IoT sensors survive load shedding?

The real failure isn't the sensor

When people ask whether their IoT will "survive load shedding," they're usually picturing a sensor frying. That's not the problem. Industrial sensors are robust and draw almost nothing. The failure that actually hurts is quieter: the system stops seeing. The moment grid power drops, a cloud-dependent deployment loses its gateway, its router, or both — and from that instant until power returns, nothing is recorded. You don't get an alarm. You get a gap.

And the gap matters more than it looks. The transitions into and out of an outage — equipment shutting down hard, restarting under load, pumps losing prime, cold chain drifting, generators picking up — are often exactly the events you most want a record of. A monitoring system that goes blind precisely when conditions get interesting isn't monitoring; it's reporting the easy hours and hiding the hard ones.

The four things that actually go down

• Connectivity. Your Wi-Fi router, fibre ONT or 4G modem usually share the building's power. When it goes, so does the link to the cloud — even if the sensor is still alive.
• The gateway / edge device. If it has no backup power, it reboots when the power returns and any unsent readings held only in volatile memory are gone.
• The cloud round-trip. Architectures that send every reading straight to the cloud with no local store have nowhere to put data during an outage, so it's simply lost.
• The mains-powered sensor itself. A sensor wired to the same circuit as the load it watches dies with that load — and often you want to keep watching while the load is down.

Notice that three of the four are about continuity of recording and reporting, not about the sensing element. That's why the answer is architectural.

How to design IoT that rides through load shedding

1. Buffer at the edge. The edge device stores readings in non-volatile local memory and forwards them to the platform. If the link is down, data queues locally and uploads when connectivity returns — no holes. This single design choice solves most of the problem.
2. Back the critical kit with a small UPS or battery. The edge device, gateway and modem draw very little, so a modest UPS or battery pack carries them through a typical 2–2.5 hour slot. Keep recording even while the heavy plant is off.
3. Make sensors independent of the load they watch. Power monitoring sensors from a backed-up rail, not from the circuit they're measuring, so you can see the load going down and coming back.
4. Use store-and-forward connectivity. Low-power networks like LoRaWAN and NB-IoT tolerate intermittency well; pair them with edge buffering so a dropped link is a delay, not a loss (see our connectivity guide).
5. Sync and reconcile on recovery. When power and network return, the system uploads the buffered window and timestamps it correctly, so your dashboards and reports show a continuous record across the outage — not a gap with a question mark.
6. Alert on the outage itself. Treat a power loss as a monitored event: log when the site dropped, how long it was down, and what state things were in on either side. That turns load shedding from a blind spot into useful operational data.

Remote sites: cut the grid dependency entirely

For a borehole, a remote reservoir, a field weather station or a livestock water point, the cleanest answer is to stop depending on Eskom at all. The power budget of an edge device plus low-power sensors and a LoRaWAN/NB-IoT radio is small enough that a modest solar panel and battery runs it indefinitely, with no grid connection to lose. Load shedding simply doesn't apply. We cover the sizing of this in our solar-powered monitoring guide — but the principle is simple: at remote-site power levels, off-grid is often easier and more reliable than fighting the grid.

What "load-shedding-proof" really means

It doesn't mean your plant keeps producing through an outage — that's a generator and energy question. It means your visibility never goes dark: every reading is captured, the record is continuous across the outage, and you can see exactly what happened before, during and after. The difference between a system that does this and one that doesn't is entirely in how it was architected — and it has to be designed in from the start, because bolting resilience onto a cloud-only system afterwards is expensive and never quite complete.

This is baked into how we build at addanode. Every deployment on the addaNet platform buffers at the edge and reconciles on recovery, and we size backup power for the gateway as standard — because we engineer for South African sites, not imported assumptions. It's the same resilience that underpins our water and mining monitoring work, where an outage is often the exact moment the data matters most.

Frequently asked questions