A plant’s internet connection going down is a question every rollout asks eventually, usually during the pilot, sometimes on day one. The short answer is that the machines don’t stop being read just because the cloud connection is gone. The gateway keeps polling on its own, stores what it reads locally, and sends the whole gap up once the connection comes back. This guide covers how that works, what a real recorded outage looked like, and what’s still an open question, not yet a proven bound.
The gateway doesn’t stop reading
Polling a machine’s PLC or control happens entirely on the gateway itself, independent of whether the cloud connection is up. When the uplink drops, wired, WiFi, or cellular, the gateway keeps issuing the same reads on the same schedule it always has, and stores every reading in a local buffer instead of sending it immediately. Nothing about the machine-side connection changes during an outage. The gap is entirely on the cloud side.
This matters most for the numbers a shift cares about. A part counter still increments, a run-state bit still flips, an alarm still trips, all captured with their real timestamps the moment they happen. None of that depends on a live cloud connection existing at the instant it occurs, which is the property that makes buffering and backfill possible in the first place. The gateway isn’t trying to catch back up on data it never had. It’s delivering data it already captured, late.
The local buffer, and its real limits
Readings wait in a bounded local store on the gateway’s own disk while the connection is down. That store has a real ceiling, both a maximum row count and a maximum size on disk, on the order of a million rows or roughly one and a half gigabytes by default, whichever limit is reached first, so a long enough outage can’t fill the gateway’s storage and take the device down with it. The gateway also watches its own free disk space directly, and stops appending to the buffer well before the disk itself would fill. That keeps a runaway outage from starving the operating system’s own partition.
If a buffer ever does fill, the oldest readings are the ones dropped first, not the newest, on the reasoning that the most recent data is the most actionable once the connection returns, and a dropped reading is counted and surfaced instead of discarded. A short or moderate outage, the overwhelming majority of what happens in the field, never gets close to that ceiling. It exists as a backstop for the rare case, not as a limit anyone should expect to hit in normal operation. At a typical light-to-moderate tag load, the default row and byte caps represent days of backlog, not minutes.
What’s proven, and what isn’t yet
On a real gateway in the field, an 82-minute outage was staged at light tag load to test exactly this path. The gateway marked itself offline in under a minute, kept buffering the whole time, and once the connection returned, every one of the 34 readings taken during the gap backfilled with full cadence continuity, no gaps in the timeline once it was over. The buffer drained back to zero, nothing was dropped, and the gateway never needed a restart to recover on its own.
That result holds for a light tag load. The same buffering mechanism is designed to scale further, but the specific bound at a heavier tag load, more sources, more tags, a longer outage, hasn’t been measured yet. A follow-up test at a longer duration and a simulated heavier load is planned to establish that bound directly, reading the buffer’s own depth and byte count at the moment the connection returns, instead of assuming from the lighter test. Until that measurement exists, treat the 82-minute, light-load result as what’s proven today, not as a guarantee for every configuration.
None of that changes the mechanism itself, only how far it’s currently been pushed. The buffer’s row and byte caps, and the eviction behavior once they’re hit, apply the same way regardless of tag count. What a heavier load changes is how much of that ceiling a given outage consumes, the number to ask about directly if a site’s tag count is unusually high.
Why buffer and backfill, instead of just retrying
The simpler design, retry each reading live and drop it if the send fails, would either lose the data an outage created or flood the network the moment it came back, every retried send competing with everything else trying to reconnect at once. Storing locally and sending the backlog in order once the link is healthy avoids both problems. Nothing produced during the gap is lost, and the catch-up happens as one orderly upload. No burst of retries fights over the same restored bandwidth. It also means the gateway doesn’t need to know, in the moment, whether an outage will last ten seconds or two hours. The same buffering behavior covers both, and the only real difference between a short blip and a long outage is how much backlog is waiting when the connection comes back.
What it looks like standing at the gateway
Someone at the panel during an outage isn’t blind either. The gateway’s own on-device console, reached directly on the plant network, not through the cloud, computes its status entirely locally: which tags are reading, when each one last updated, what the machine-side connections look like. None of that depends on the uplink being up, so a technician troubleshooting a suspected machine-side problem can confirm the gateway is still reading real values even while the cloud dashboard shows the site offline. The two views answer different questions. The console says whether the gateway can still see the machine. The cloud dashboard says whether that data has made it to Spall yet.
What the dashboard shows while a site is dark
A gateway that’s stopped sending data shows as offline, not as a flatline that could be mistaken for the machine sitting idle. The distinction matters: a flat “everything’s fine” chart during a real outage would be actively misleading. A “no data, connection down” gap is the accurate picture of what’s known at that moment. Once the connection returns and the buffered readings backfill, the timeline fills in behind that gap with the real values the gateway captured the whole time, not an estimate and not a smoothed-over interpolation.
Quick recap
- The gateway keeps polling machines and buffering locally during an outage, the cloud connection is the only thing that pauses
- The local buffer is bounded, both in row count and disk size, with the oldest readings dropped first if it ever fills
- A real 82-minute outage at light tag load backfilled all 34 in-gap readings with full cadence continuity and zero drops, no restart needed
- The heavier-load bound, more tags, more sources, a longer outage, hasn’t been measured yet, so treat that result as proven at light load, not as a universal guarantee
- The dashboard shows a labeled offline gap during an outage instead of a flatline, and fills it in with real backfilled data once the connection returns