Report-by-exception is what makes DNP3 efficient, but it depends on the outstation remembering what changed until the master asks for it, and that memory is finite. The DNP3 event buffer is that memory: a fixed-size queue where an outstation holds each Class 1, 2, or 3 event between reports so that no change is lost even when the master is slow to poll or the link is down. This guide explains what the event buffer is, why its size matters, what happens when it overflows, and how it ties into report-by-exception on low-bandwidth links.
DNP3 event buffer in one line: A DNP3 event buffer is a fixed-size queue in an outstation where it stores events, the timestamped records of point changes, until they can be reported to the master. Events are sorted into Class 1, 2, and 3 buffers, and they wait there so that changes captured between polls are not lost. Because the buffer holds a limited number of events, if it fills before the master collects them, the oldest events are typically dropped and the outstation sets an internal indication bit to warn the master that data was lost.
In DNP3, an outstation does not just hold the current value of each point; when a point changes in a way worth reporting, the outstation creates an event, a record that captures the new value, its quality flags, and usually a timestamp of when the change happened. These events are queued in the event buffer, waiting to be sent to the master. The buffer exists because the master does not read every change the instant it occurs; it collects events periodically by polling, or receives them when the outstation sends them unsolicited, and in between the outstation must remember each change in order. The buffer is that ordered memory.
Events are organised by class. DNP3 defines Class 1, Class 2, and Class 3 as event classes, and each point that generates events is assigned to one of them, letting an engineer group high-priority events into a class that is polled or reported more often and lower-priority events into a class polled less frequently. The outstation maintains buffering for these event classes, and the master can poll for a specific class to retrieve just those events. This class structure is what lets DNP3 prioritise, so that an important status change can be reported promptly while routine analog updates are collected on a slower cadence.
The essential characteristic of the buffer is that it is finite. An outstation has a limited amount of memory, so it can only hold a bounded number of events at once, a capacity set by the device's design or configuration. As long as the master collects events faster than they accumulate, the buffer stays comfortably below its limit and every change is delivered. The whole scheme rests on this balance between how fast events are generated and how promptly they are read, and the buffer's job is to absorb the gap between the two.
Buffer size determines how much of a gap between event generation and event collection the outstation can absorb without losing anything. If a burst of activity generates many events quickly, or if the master goes quiet for a while, the events pile up in the buffer, and the buffer needs enough depth to hold them until the master catches up. Too small a buffer, and even a modest delay or a short flurry of changes overruns it; a well-sized buffer rides out the normal variability of polling and communications so that no event is dropped in ordinary operation. Sizing is therefore a trade between the outstation's memory and the worst-case backlog it must tolerate.
When the buffer does fill and another event arrives with no room for it, the outstation must overflow, and the standard behaviour is to discard the oldest event to make room for the newest, so the most recent changes survive while the earliest are lost. Losing the oldest events is generally the least-bad choice, but it still means a gap in the record: some changes that occurred are simply never reported. The consequence is that the master's picture can diverge from what actually happened at the outstation, which is exactly the situation a robust system needs to detect rather than silently accept.
DNP3 handles this with a warning flag. When an event buffer overflows, the outstation sets a bit in its Internal Indications, the status word every outstation returns to the master, specifically the indication that an event buffer has overflowed and events were lost. When the master sees that bit, it knows its event record is incomplete and can respond, typically by performing an integrity poll that reads the current static values of all points, re-synchronising its view of the outstation's present state even though the intermediate events are gone. The overflow bit does not recover the lost events, but it ensures the loss is known and the master can restore a consistent picture.
The event buffer is the mechanism that makes report-by-exception work, and report-by-exception is what makes DNP3 suit slow, expensive, or intermittent communication links. Rather than the master repeatedly polling every point's full value, which wastes bandwidth re-sending values that have not changed, the outstation buffers only the changes as events and reports just those. On a narrowband radio, a satellite link, or a cellular connection billed by the byte, this is an enormous saving, because most points do not change most of the time, and only the events, the actual changes, travel over the link.
Buffering also makes the system resilient to interruptions in that link. If communications drop for a period, the outstation keeps capturing events into its buffer, and when the link recovers the backlog is delivered so the master learns everything that happened during the outage, in order and with timestamps. This is precisely where buffer sizing earns its keep: the buffer must be deep enough to hold all the events that could accumulate during a plausible communications outage, or the overflow will discard the earliest changes and the record of the outage period will have a hole. On a link that drops out regularly, generous buffering is what preserves a complete history.
This is directly relevant to how a cloud SCADA platform such as Merobix gathers data from remote field sites, which in oil and gas, water, and similar industries are often on exactly these low-bandwidth, sometimes-unreliable links. Outstations at wellheads, tanks, and remote stations buffer their events and report by exception, and the platform collects those events efficiently and reacts to a buffer-overflow indication by re-polling to re-synchronise. Understanding the event buffer explains both why such a system is bandwidth-thrifty and why an occasional integrity poll is necessary: the buffer keeps the normal traffic tiny, and the overflow flag plus a full poll is the safety net that guarantees the central picture stays correct even when a site's events briefly outrun its buffer.
When the buffer is full and a new event arrives, the outstation typically discards the oldest event to make room for the newest, so the most recent changes are kept but the earliest are lost. It also sets a buffer-overflow bit in its Internal Indications to tell the master that events were lost. The master usually responds with an integrity poll to re-read the current values of all points and restore a consistent view.
DNP3 defines Class 1, Class 2, and Class 3 as event classes, and each event-generating point is assigned to one of them. This lets engineers group higher-priority points into a class that is polled or reported more frequently and lower-priority points into a class collected less often. The master can poll for a specific class to retrieve just those events, which is how DNP3 prioritizes what gets reported first.
Report-by-exception means the outstation reports only changes rather than every point's full value on every poll, which the event buffer makes possible by storing those changes until the master collects them. This keeps traffic small on slow or costly links, since unchanged points are not re-sent. The buffer also holds events through a communications outage so the backlog is delivered when the link returns, as long as it does not overflow first.
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.