Remote telemetry links fail - a cellular tower congests, a storm blocks a satellite, a radio path drops. Store and forward is the mechanism that makes those outages harmless: the field device quietly saves its readings while the link is down and delivers all of them, timestamped, the moment communications return. This guide explains how store and forward works and why it is essential for oil and gas monitoring.
What Is Store and Forward? in one line: Store and forward is a technique where a field device buffers timestamped readings locally when its communication link is unavailable, then transmits the stored backlog to SCADA once the link is restored. It prevents data loss and history gaps during comms outages on remote sites.
An RTU or edge gateway with store and forward continuously logs its readings to local nonvolatile memory, each with an accurate timestamp from its own clock. As long as the link is up, it forwards data normally. When the link drops, the device keeps logging to its buffer instead of discarding readings. When connectivity returns, it sends the buffered records - the backfill - to the host, which inserts them into history at their original timestamps.
The two things that make this work correctly are timestamping at the source and adequate buffer depth. Because each record carries the time it was actually measured, not the time it was finally delivered, the SCADA historian can reconstruct an accurate, gap-free trend even though the data arrived late. Buffer depth - how many hours or days of data the device can hold - determines how long an outage it can survive without overwriting the oldest records.
Oil and gas telemetry lives at the edge of the network: wellsites on cellular plans, pipeline points on radio, remote facilities on satellite. Outages are not rare exceptions but a routine part of operations. Without store and forward, every dropout punches a hole in your production history - lost volumes, missing pressures, blind spots in exactly the records you need for allocation, compliance, and troubleshooting.
Store and forward turns an outage into a delay rather than a loss. Production totals reconcile correctly once the backfill arrives; trend charts fill in; regulatory records stay complete. For custody transfer and allocation, where every barrel and MCF must be accounted for, source-timestamped buffering is not a nicety - it is a requirement. Protocols like DNP3 include event buffering explicitly, and MQTT with Sparkplug B supports store-and-forward patterns at the edge.
Cloud SCADA depends on store and forward at two layers. At the field layer, the RTU or gateway buffers during comms loss to the cloud. Well-designed edge gateways add their own store-and-forward stage, buffering to disk if the internet uplink fails and backfilling the cloud platform when it recovers - so a WAN outage between site and cloud is just as survivable as a field radio dropout.
When the backfill lands, the platform must accept out-of-order, historically timestamped data and slot it into the correct place in history rather than stamping it 'now.' Merobix ingests store-and-forward backfill from DNP3 RTUs, flow computers, and MQTT/Sparkplug B gateways, honoring each record's original timestamp so history stays accurate through outages.
It is a method where a field device saves timestamped readings locally during a communications outage and sends the whole backlog to SCADA when the link returns. Because the data is timestamped at the source, the historian can fill the gap accurately, so no history is lost during a dropout.
Remote wells, pipelines, and facilities rely on cellular, radio, and satellite links that regularly drop. Store and forward ensures production volumes, pressures, and other records survive those outages intact - critical for allocation, custody transfer, and regulatory reporting where every barrel and MCF must be accounted for.
They solve different problems. A heartbeat is a periodic 'I'm alive' message so the host can tell a stable value from a dead link. Store and forward is buffering data during an outage and backfilling it afterward. A device often uses both - a heartbeat to prove health and store-and-forward to protect data through comms loss.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.