Status code · Good
GoodOverload
GoodQueue overflow
GoodOverload is not an error, and that is the problem: it reports a Good severity while telling you samples were lost. A monitored item queue overflowed and the server dropped values. Nothing downstream will notice unless you inspect the status, so instrument the overflow explicitly and raise QueueSize.
Defined behaviour: The operation succeeded but sampling has been slowed or values have been discarded because the item could not keep up. (our description of the condition this code reports)
What you actually see
The data looks continuous and plausible but samples are missing - a counter jumps, a cycle is absent, a fast transient never appears - and no error is logged anywhere.
Why it happens
- Publishing interval much slower than the sampling interval with QueueSize 1The server samples at the sampling interval and drains the queue at the publishing interval. Sampling at 50 ms and publishing at 1000 ms produces twenty samples per cycle, and a queue of one keeps a single value. Nineteen are discarded every second, reported as Good with an overflow indication. This is the single most common cause of silent data loss in OPC UA.
- Queue sized without reference to the interval ratioQueueSize should be at least the publishing interval divided by the sampling interval, plus headroom for jitter. Left at the default of one, or set to an arbitrary small number, it discards whenever the source produces faster than the publish cycle drains.
- DiscardOldest hiding which samples wentDiscardOldest true drops the oldest queued values, so you keep the most recent and lose history; false drops the newest, so you keep the oldest and lose current state. Neither is wrong, but code that does not know which is configured cannot reason about what is missing.
- Server slowing sampling under loadUnder pressure a server may sample less often than requested rather than fail. The revised sampling interval returned at creation is the honest figure; a server that degrades further at runtime signals it here. The effect is the same as a slower sampling interval you did not ask for.
- Client not draining because Publish is not outstandingQueues drain when a Publish is available to carry the notification. A client with a slow notification handler, or too few outstanding Publish requests, leaves the server holding values until the queue overflows. The overflow is then caused by the client, not by the server.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Instrument the overflow indication and alarm on itThe overflow condition is carried as a flag inside the StatusCode rather than as a separate code, so a consumer that only compares against Good will never see it. Extract the flag bits, count overflows per item, and treat a non-zero count as a defect. The documented pattern for a Good status carrying the overflow flag is the value 1152, hexadecimal 0x480, where the upper sixteen bits give the severity and the lower sixteen carry the flags.
- Size QueueSize from the interval ratioSet QueueSize to at least the publishing interval divided by the sampling interval, then add headroom - a factor of two is a reasonable start. For a 100 ms sampling interval on a 1000 ms publishing interval, ten is the floor and twenty is a safer setting. Increase it until the overflow count stays at zero.
- Reconsider whether you need the fast sampling at allIf the consumer works on one-second data, sampling at 50 ms and discarding nineteen samples costs server CPU for nothing. Either slow the sampling interval to match the consumer, or keep it fast and queue properly because you genuinely need every sample. Doing neither is the worst option.
- Set DiscardOldest deliberately per itemFor a current-state value such as a temperature or a machine state, DiscardOldest true is right: you want the latest. For an event-like signal such as a cycle-complete pulse or a counter you intend to difference, losing any sample corrupts the result, so the answer is a queue large enough not to discard rather than a choice of which end to drop.
- Keep Publish requests outstanding and handlers fastCap outstanding Publish requests explicitly, but do not set the cap so low that queues cannot drain. Move all work out of the notification callback into a worker queue so a Publish is reissued immediately.
- Compare the revised intervals against what you requestedLog the revised sampling interval and revised publishing interval from the create responses. Sizing a queue against requested values while the server granted something different is how a correctly reasoned queue still overflows.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| OPC Publisher | Queue overflow is documented as silent unless you look for it: the overflow bit lives inside the StatusCode, so a data-loss condition is reported as Good. The guidance is to raise QueueSize until the overflow instrument stays at zero. |
| UA-.NETStandard (C#) | MonitoredItem.QueueSize and DiscardOldest are set before ApplyChanges, and the revised sampling interval is available in MonitoredItem.Status. StatusCode exposes the flag bits, so check the overflow flag rather than comparing the whole code to Good. |
| node-opcua | queueSize and discardOldest are part of the monitoring parameters, and the notification's statusCode carries the overflow indication. A handler that branches only on statusCode.isGood will treat a lossy stream as healthy. |
| asyncua (Python) | Set queuesize in the monitored item parameters rather than relying on the default of one, which is what the simple subscribe_data_change path gives you. Inspect the DataValue status flags in the callback. |
| open62541 (C) | The monitored item request carries queueSize and discardOldest, and the returned status code's info bits carry the overflow indication. Both are directly accessible, so counting overflows per item is straightforward. |
| Ignition | Tag group rate and the underlying subscription's publishing interval interact with queue depth. Where fast transients are being missed, review both the rate and the queue depth rather than only the rate. |
What it looks like in the log
MonitoredItem ns=3;s=Line1.CycleDone: notification with overflow flag set, 12 values discarded
QueueSize 1 with samplingInterval 50 ms and publishingInterval 1000 ms; expected discard rate 95 percent
Overflow count for subscription 2 since start: 4412Confirm the fix
Set the overflow counter to zero, run for a period covering your busiest production condition, and confirm it stays at zero; separately, compare a counter's differenced total against the machine's own totaliser over the same window.
Stop it happening again
Make the overflow flag a monitored metric in every collector, compute QueueSize from the revised publishing-to-sampling ratio automatically rather than by hand, and treat any non-zero overflow count as a build-blocking defect in commissioning tests.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.