What Happens When a LoRaWAN Gateway Goes Offline? Data Loss, Sensor Behaviour and How to Design Around It
Short Answer
While a LoRaWAN gateway is offline, its sensors keep transmitting on schedule, but nothing hears them. Every reading sent during the outage is lost unless the sensor stores readings locally and re-sends them later. The sensors don’t know anything is wrong: a Class A device transmits, listens briefly for a reply it doesn’t expect, and goes back to sleep.
Two side effects catch most operators out:
- Sensors slowly turn themselves up. With adaptive data rate enabled, a sensor that hears nothing back for long enough raises its transmit power and drops step by step to SF12. Batteries drain faster, and when the gateway returns the channel is crowded with slow packets until ADR brings everyone back down.
- Alarms don’t get through. A threshold alert sent during the outage is just another unheard uplink. Downlinks queued on the server wait until the sensor is heard again.
How much you actually lose depends on which part failed. A gateway with a built-in network server keeps the site running through an internet outage; a dual-backhaul gateway rarely goes offline at all; a sensor with local data logging covers the rest. This guide walks through each case.
The Four Places a LoRaWAN Network Can Break
“The gateway is offline” usually means one of four different failures, and they don’t lose the same data.
| What failed | What the sensors experience | What is lost | What prevents the loss |
|---|---|---|---|
| Gateway power or hardware | Silence; nothing in range hears them | Every uplink during the outage, alarms included | Device-side data logging; a second gateway with overlapping coverage; UPS or PoE from a backed-up switch |
| Gateway backhaul (broadband, Wi-Fi, 4G) | Nothing; the gateway still receives them | With a plain packet forwarder, everything; with a gateway running its own network server, nothing at site level | Built-in network server; dual backhaul with failover; gateway-side buffering |
| Network server (cloud VPS down) | Nothing | Everything the gateway can’t deliver, unless it buffers or runs a local server | Edge or on-premise network server; a high-availability cloud server |
| Application or dashboard | Nothing; the network server still receives | Usually nothing: the server keeps the events; integrations retry | MQTT with persistent sessions; server event history |
The first row is the true blackout. The other three are backhaul problems with the same symptom on the dashboard, and the right hardware turns them into non-events.
What the Sensors Do While the Gateway Is Down
They keep transmitting, unheard
A standard LoRaWAN sensor uses unconfirmed uplinks: it sends, opens two short receive windows, and sleeps. It gets no acknowledgement in normal operation either, so an outage looks exactly like a normal day from the sensor’s side. It samples, transmits, sleeps, repeats. Each transmission that nothing receives is gone.
This is different from Wi-Fi, where a sensor knows immediately whether it has a connection. A Wi-Fi sensor such as the MacSync WT1 detects the lost network, keeps logging to its 30,000-record memory and uploads the backlog when the network returns. A LoRaWAN Class A sensor can’t tell the gateway has gone unless it asks for an acknowledgement, which is why device-side logging has to be designed in rather than assumed. See LoRaWAN vs Wi-Fi Temperature Sensor for the wider comparison.
ADR back-off: sensors drift to SF12
Adaptive data rate has a safety mechanism that works against you during an outage. A sensor with ADR enabled counts uplinks since its last downlink of any kind. After 64 uplinks it starts asking the network for a reply. If 32 more pass in silence, it assumes it has lost the network and tries to regain it: first by stepping transmit power up to maximum, then by lowering its data rate one step every 32 uplinks until it reaches SF12.
Those are the LoRaWAN defaults for IN865 (ADR_ACK_LIMIT = 64, ADR_ACK_DELAY = 32). For a fleet starting at SF7:
| Reporting interval | Back-off begins (96 uplinks) | Sensors reach SF12 (256 uplinks) |
|---|---|---|
| 5 minutes | 8 hours | about 21 hours |
| 15 minutes | 24 hours | about 2.7 days |
| 60 minutes | 4 days | about 11 days |
Sensors that were already at SF9 or SF10 get there sooner. The consequences:
- Battery. A packet at SF12 stays on air roughly 24 times longer than at SF7. A sensor parked at SF12 and maximum power at a 5-minute interval spends its battery several times faster than it was designed to. The numbers are in How Long Do LoRaWAN Sensor Batteries Last?
- Capacity. When the gateway returns, every sensor is transmitting slow, long packets on the same eight channels. Collisions rise until ADR has pulled them back down.
- Duty cycle. At SF12 a short heartbeat every 5 minutes still sits within India’s 2.5% device limit, but longer batch payloads can approach it. See LoRaWAN in India: IN865 and WPC Rules.
Sensors with ADR disabled stay at their fixed spreading factor and avoid all of this, at the cost of never optimising in normal operation.
Confirmed uplinks don’t save the data
Switching to confirmed uplinks tells the sensor its message failed; it doesn’t make the message arrive. The sensor retries, typically up to eight transmissions with the data rate stepping down as it goes, then gives up on that message. Each retry costs airtime and battery, the reading is still lost, and a fleet of sensors all retrying at once makes the recovery worse.
Confirmed uplinks are useful for one thing here: as the trigger for a device with local storage to know when to hold data and when to release it. On their own they’re an expensive way to learn what you already know.
Sensors that reboot during the outage have to rejoin
A sensor that loses power during the outage has to complete an OTAA join before it can send data again, and join attempts are rate-limited by the standard. Join requests are held to about 1% duty cycle in the first hour after a reset, 0.1% for the next ten hours, and 0.01% after that. A sensor that rebooted at the start of a long outage may take hours to rejoin once the gateway is back, which is one more reason to keep gateways powered through mains failures.
Sensors that stayed powered don’t rejoin; their session survives the outage, and their frame counters simply jump forward when they’re heard again. The server accepts the gap. Counter trouble appears only after outages of many weeks, or with ABP devices that were reset without rejoining.
What Happens When the Gateway Comes Back
Recovery is automatic, but it isn’t instant.
- The first uplink gets through on the sensor’s next scheduled transmission. The dashboard shows a gap and then a new reading, nothing more.
- Queued downlinks are delivered. Configuration changes or commands queued on the network server during the outage go out in the receive window after that uplink. Check the queue first if several piled up.
- ADR pulls sensors back down. The server needs a short history of uplinks at the current data rate before it changes anything; ChirpStack’s default uses the last 20. Expect sensors to be pushed back to a faster rate within a few hours at a 15-minute interval, sooner at 5 minutes.
- Rebooted sensors rejoin as their back-off allows.
- Buffered data arrives, if anything buffered it. Device-side logs come in as batch uplinks over the next few cycles. Gateway-side buffers replay in a burst.
One caution on gateway-side replay: a network server validates frame counters to block replay attacks. If a gateway replays stored packets after newer ones have already been accepted, the older frames are rejected as replays. Device-side logging avoids this, because the sensor controls the order.
Where Buffered Data Can Live
There are three places a reading can wait out an outage, and they aren’t equal.
| Where | What it protects against | Limits |
|---|---|---|
| In the sensor (local data logging) | Everything: gateway, backhaul and server failures | Capacity and the mechanism for knowing when to re-send; the gold standard if the device supports it |
| In the gateway (buffering, or a built-in network server) | Backhaul and cloud failures, not gateway failure | Needs power; replaying raw packets can collide with frame-counter checks; a built-in server avoids that by processing locally |
| In the network server (event store, MQTT persistence) | Dashboard and integration failures | Nothing if the server itself is what failed |
How Macnman sensors handle an outage
The MacSync LTS X1 separates its sampling interval from its uplink interval: it can sample every minute and transmit every 15, carrying the intermediate readings as a batch uplink. Readings are logged in the sensor’s local storage on the sampling schedule whether or not a gateway is listening. [VERIFY, then pick one: (A) “Readings logged during an outage are held and re-sent as batch uplinks once the sensor is heard again, up to N records, so a gateway outage shorter than the log capacity loses nothing.” / (B) “Readings logged between uplinks travel in the next batch, so a short outage of a cycle or two is bridged; readings older than the log window are not re-sent.”] The batch format itself is described in LoRaWAN Payload Decoder for Temperature Sensors.
The sensor’s threshold alarms also keep evaluating during an outage. The alarm uplink itself may be lost, so for safety-critical limits pair device logging with gateway redundancy or a local alarm path, both covered below.
How Macnman gateways handle a backhaul outage
Both the MacLink Gen-2 outdoor gateway and the Setu LX indoor gateway run a built-in ChirpStack network server and Node-RED on the gateway itself, with 8 GB of local storage. When the site’s internet drops, the gateway keeps receiving, decrypting and storing uplinks locally, and local automation keeps running. Nothing at site level is lost; the cloud catches up when the link returns. Both gateways also carry Ethernet, Wi-Fi and dual-SIM 4G LTE backhaul, so the internet dropping on one path doesn’t take the gateway offline in the first place.
Gateway Down vs Internet Down: Not the Same Problem
Most “gateway offline” alerts in India are backhaul or power problems, not gateway faults. Broadband outages, a 4G SIM that ran out of data, a switch that lost mains, a Wi-Fi password that changed. The gateway hardware is usually fine.
That distinction decides the fix:
- Internet down, gateway powered: a gateway with a built-in network server loses nothing locally, and dual backhaul usually means the dashboard never notices either. A gateway running only a packet forwarder to a cloud server loses everything until the link returns.
- Gateway unpowered: nothing receives. Only device-side logging or a second gateway covers the gap.
So the design question is less “what if the gateway dies” and more “what keeps the gateway powered and connected”. Those are solved problems.
How to Design for Outages
In priority order, by how often each failure actually happens on Indian sites.
| Cause | Fix |
|---|---|
| Mains failure at the gateway (the most common) | Power the gateway by PoE from a UPS-backed switch, or from a 12–24 V DC battery supply. A gateway draws around 4.5 W, so even a small UPS carries it for hours and a solar-plus-battery setup runs it indefinitely outdoors |
| Broadband or Wi-Fi outage | Dual backhaul: Ethernet as primary, 4G as failover, with two SIMs on different operators. Keep the SIM data plan monitored |
| Cloud server unreachable | Run the network server on the gateway or on-premise, and bridge to the cloud with MQTT and persistent sessions. For large networks, a high-availability server |
| Gateway hardware fault or lightning | Surge protection on power and RF ports; a second gateway with overlapping coverage so every sensor is heard by two; a spare unit on the shelf |
| Human error (unplugged, moved, firewall change) | Mount gateways out of reach, label them, document the ports they need, and alert on offline status |
| Readings during any remaining gap | Sensors with local data logging and a sampling interval shorter than the uplink interval |
| Alarms during any remaining gap | Local alarm logic in Node-RED on the gateway driving a Class C output, or overlapping gateways so the alarm uplink is heard by at least one |
For the coverage side, including where to place a second gateway so its cell overlaps the first, see How Far Can a LoRaWAN Sensor Transmit? and the gateway placement guide.
How to Know a Gateway Is Offline
Set an alert on the network server’s gateway “last seen” time, and a second alert per device.
- Gateway heartbeat. A gateway sends statistics to its network server every 30 seconds or so. ChirpStack shows “last seen” on the gateway page and exposes gateway state over its API and MQTT; alert when it exceeds 5 to 10 minutes.
- Device last seen. A gateway that’s online but a sensor that’s silent for three reporting intervals is a different problem: a dead battery, a moved sensor or a new obstacle. Alert on that separately, so you don’t chase the gateway for a sensor fault.
- Remote management. Macnman gateways report to MacCloud for remote diagnostics and firmware management, which makes an offline gateway visible without a site visit.
- Uplink rate drops. A gateway that’s up but receiving half its usual traffic is a sign of an antenna, cable or interference problem rather than an outage.
Recovery Checklist After an Outage
- Confirm the gateway is up and forwarding: last seen is current, statistics are arriving, and the network server shows live uplinks.
- List sensors not yet heard since the gateway returned. Give rebooted devices time to rejoin before sending anyone to site.
- Check the downlink queue for anything that accumulated, and clear commands that no longer apply before they go out.
- Watch ADR recover. Spreading factors should fall back over the next few hours. Force a data rate only for sensors that stay stuck.
- Reconcile buffered data. Batch uplinks from device logs fill the gap on the dashboard; check for duplicates if the gateway also replayed packets.
- Review the missed window for alarms. Logged readings show whether a threshold was crossed while nobody was listening.
- Fix the cause, not the symptom: add the UPS, the second SIM or the second gateway so the next outage isn’t an outage
Build the Site So an Outage Isn’t an Event
Macnman designs and manufactures LoRaWAN hardware in India with resilience built in at both ends:
- Gateways with Ethernet, Wi-Fi and dual-SIM 4G backhaul, a built-in ChirpStack network server, Node-RED for local alarms, PoE or DC power, and surge-protected ports: the MacLink Gen-2 for outdoor and campus sites, the Setu LX for buildings. Compare them in Indoor vs Outdoor LoRaWAN Gateway.
- Sensors with local data logging and independent sampling and uplink intervals, including the MacSync LTS X1 and the rest of the LoRaWAN sensor range.
- Setup guidance for the network server in How to Connect a LoRaWAN Sensor to ChirpStack.
Already running a network that drops out? Tell us how the gateway is powered and connected and what the sensors monitor, and a product engineer will come back within one working day with the two or three changes that would make the biggest difference: contact Macnman. To try a resilient setup end to end, the pilot kit pairs logging sensors with a dual-backhaul gateway.
Frequently Asked Questions
What happens when a LoRaWAN gateway goes offline?
The sensors keep transmitting on schedule but nothing receives them, so readings sent during the outage are lost unless the sensors store data locally. With ADR enabled, sensors that go long enough without any downlink raise their power and lower their data rate towards SF12. Alarms sent during the outage are lost and queued downlinks wait until the gateway returns.
Do LoRaWAN sensors lose data when the gateway is down?
Yes, unless the sensor logs readings locally and re-sends them, or a second gateway in range is still online. Standard unconfirmed uplinks are fire-and-forget; the sensor doesn’t know the gateway is gone.
Do LoRaWAN sensors know when the gateway is offline?
Not by default. A Class A sensor with unconfirmed uplinks never expects a reply, so an outage looks normal to it. Only the ADR back-off counter eventually reacts, after 96 uplinks without a downlink, and confirmed uplinks reveal the failure at the cost of retries and battery.
Why did my sensors switch to SF12 after a gateway outage?
That’s ADR back-off. After 64 uplinks without a downlink the sensor asks for one; after 32 more it raises its transmit power, then lowers its data rate one step every 32 uplinks until it reaches SF12. Once the gateway is back and downlinks resume, ADR brings the sensors back to a faster rate over a few hours.
Do confirmed uplinks prevent data loss?
No. They make the sensor retry a few times and then give up, so the reading is still lost and the battery is spent on retries. They only help when the device uses the missing acknowledgement as a signal to hold data in local storage for later.
What happens to LoRaWAN data if the internet goes down but the gateway has power?
With a plain packet forwarder to a cloud server, the packets are dropped. With a gateway that runs its own network server, such as the Macnman MacLink Gen-2 or Setu LX with built-in ChirpStack, uplinks are received and stored locally and the cloud catches up when the link returns. Dual backhaul with 4G failover usually prevents the outage altogether.
How do I back up the power to a LoRaWAN gateway?
Power it by PoE from a switch on a UPS, or from a 12–24 V DC battery supply. A typical gateway draws about 4.5 W, so a small UPS keeps it running for hours and a solar-plus-battery setup runs it continuously outdoors.
How do I get alerted when a LoRaWAN gateway goes offline?
Alert on the network server’s gateway “last seen” time. Gateways send statistics every 30 seconds or so; a gap of more than 5 to 10 minutes means it’s offline. Add a separate per-sensor alert so a single dead sensor isn’t mistaken for a gateway failure.
Can two gateways provide redundancy?
Yes. LoRaWAN gateways aren’t paired with sensors, so a sensor heard by two gateways keeps reporting if one fails. The network server deduplicates the packets. Place the second gateway so its coverage overlaps the sensors that matter most.
Will a LoRaWAN sensor rejoin automatically after an outage?
A sensor that stayed powered doesn’t need to; its session survives and it’s heard again on its next uplink. A sensor that rebooted during the outage rejoins automatically, but join attempts are rate-limited by the standard, so it may take hours after a long outage.
