Report by exception, or RBE, is the simple but powerful idea that a field device should only send a value when it has actually changed enough to matter. On cellular and satellite links where every byte and every second of airtime has a cost, RBE is the difference between an affordable telemetry bill and an impossible one. This guide explains how report by exception works, how deadbands control it, and where it fits.
What Is Report by Exception? in one line: Report by exception is a telemetry method in which a device transmits a value only when it changes by more than a defined threshold (a deadband), rather than on a fixed timer. It cuts bandwidth and power dramatically by sending updates when data is meaningful instead of constantly.
With RBE, the field device holds the last value it reported and continuously compares the current reading against it. Only when the difference exceeds a configured deadband does the device transmit a new value. A tank level that drifts a few hundredths of a foot generates no traffic; a level that moves a full foot, or a pressure that jumps, is reported immediately. The result is that quiet processes are nearly silent on the wire and real changes propagate right away.
Most implementations pair the change deadband with a heartbeat or integrity timer - a maximum interval (say 15 minutes or an hour) after which the device reports its value even if nothing changed. The heartbeat proves the device is still alive and communicating, so a long silence genuinely means something is wrong rather than simply stable. Without a heartbeat, RBE and a dead radio look identical to the host.
Polling asks every device for its value on a fixed cycle regardless of whether anything changed, so bandwidth usage is constant and predictable but often wasteful. RBE is event-driven: the device decides when to speak. For a field of hundreds of wells where most tags are stable most of the time, RBE can cut telemetry volume by an order of magnitude compared with second-by-second polling.
The trade-offs are worth understanding. RBE gives you excellent temporal resolution on the changes that matter and near-zero traffic when nothing happens, but you no longer get a guaranteed sample every N seconds, so trend charts are unevenly spaced. It also depends on the deadband being set well - too tight and you flood the link with noise; too loose and you miss meaningful movement. Protocols like DNP3, and MQTT with Sparkplug B, are built around report-by-exception behavior.
RBE is standard practice in upstream and midstream telemetry precisely because the assets are remote and the comms are metered. An RTU at a wellsite on a cellular plan reports tank levels, pressures, and flow rates by exception, sending a burst when a truck loads a tank or a pump cycles and staying quiet otherwise - while a heartbeat confirms health.
On the host side, a SCADA platform must handle exception-reported data correctly: apply the reported timestamp, interpolate sensibly for trends, and distinguish 'no change' from 'no comms' using the heartbeat. Merobix reads report-by-exception data from DNP3 RTUs, flow computers, and MQTT/Sparkplug B publishers, storing each reported change with its native timestamp for accurate history.
It is a data-reporting method where a field device sends a value only when it changes by more than a set threshold, instead of on a fixed schedule. This conserves bandwidth and power on cellular, radio, and satellite links, which is why it is common in remote oil and gas telemetry.
Polling requests every value on a fixed timer whether or not it changed, so traffic is constant. Report by exception is event-driven - the device transmits only on meaningful change, so quiet tags produce almost no traffic and real changes are sent immediately. RBE usually adds a heartbeat timer to confirm the link is alive.
Because with pure RBE, a stable value and a dead communication link both produce silence. A heartbeat (integrity) timer forces the device to report at a maximum interval even when nothing changed, so the host can tell a genuinely quiet process from a failed radio or offline device.
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.