Status code · Uncertain
UncertainLastUsableValue
UncertainStale data
UncertainLastUsableValue is not an error. The server is deliberately telling you the number is the last good reading and is now stale. Treat it as a hold, not as data: check SourceTimestamp for age, exclude it from averages and OEE, and find why the source stopped confirming.
Defined behaviour: The value is the last one known to be usable, but the source is no longer confirming it and its age is not bounded. (our description of the condition this code reports)
What you actually see
A tag keeps showing a plausible, unchanging value while the timestamp stops advancing, and downstream trends flatline instead of going bad.
Why it happens
- Source stopped responding and the server is holding the last readingWhere a device times out, many servers keep the last successfully read value and downgrade its status rather than discarding it. This is deliberate: an operator screen showing the last known temperature with a degraded indicator is more useful than a blank. The value is real but historical.
- Aggregating server holding values from a downstream serverA gateway or aggregating server that loses its upstream connection can present the last cached values with this status. The client's own connection is perfectly healthy, which is why the problem looks like a data quality issue rather than a communication one. The failure is one hop further away than it appears.
- Redundant or fail-over source where the standby has no fresh dataDuring a fail-over the new source may not yet have current values, so what it can serve is the last usable reading from before the switch. The window is short but it lands exactly at the moment your data matters most.
- Slow or intermittent field busA serial or wireless segment that drops occasional polls produces brief runs of this status between good samples. Individually harmless, but a client that averages without checking status will blend held values into the mean and understate variance.
- Server-side scan disabled or the item removed from scanA tag removed from the scan list, or a channel paused, stops being refreshed while the cached value remains available. The status is the only signal that the number is no longer being maintained.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read SourceTimestamp and compute the ageThe status says the value is stale; SourceTimestamp says how stale. Compare it against the sampling interval you expect. An age of two intervals is a hiccup; an age of two hours means the source has been gone since the last shift and nobody noticed.
- Exclude held values from every calculationDo not feed this status into availability, performance, quality, averages, totals or rate calculations. A held value repeated for an hour will drag an average toward it and produce an OEE figure that is quietly wrong. Mark the interval as no-data and let the aggregation report reduced coverage.
- Trace back one hop at a timeCheck whether the OPC UA server itself is healthy - it is, if it is answering you - then look at its device or upstream connection status. In an aggregation chain, connect directly to the downstream server and read the same node to find which hop lost the source.
- Distinguish held from failed in your alarmsAlarm on the status class, not on the value. A rule that fires when a tag reports uncertain for longer than a defined tolerance catches this while a value-range alarm never will, because the held value is inside range by definition.
- Decide the hold policy deliberatelyWhere the server lets you choose between holding the last value and reporting a hard failure, choose per use case. Operator displays benefit from a held value with a quality indicator; an analytics feed is better served by an explicit bad status that its pipeline cannot mistake for data.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | The Data Access View shows the status alongside the value, and watching SourceTimestamp stop advancing while the value stays put is the clearest confirmation you are looking at a hold rather than a genuinely steady process. |
| asyncua (Python) | In your data change handler test the DataValue's status before using the value. Emit an explicit stale marker downstream rather than dropping the sample, so a gap in the pipeline is distinguishable from a collector outage. |
| OPC Publisher | The status travels with the value, so a downstream consumer can act on it - but only if it inspects it. In the JSON encoding a Good status is omitted, so any status present in the message is worth branching on. |
| Ignition | The tag shows an uncertain quality overlay and the historian records the quality if configured to. Enabling quality storage is what makes it possible to exclude these intervals from reports after the fact. |
| KEPServerEX | Device-level timeout and demotion settings decide whether a stale tag holds its last value or reports a failure. Review those settings so the behaviour matches what your consumers expect. |
| UA-.NETStandard (C#) | StatusCode exposes helpers for the severity class, so branch on the uncertain class rather than comparing the whole code. Log the SourceTimestamp delta whenever the class changes. |
What it looks like in the log
ns=3;s=Oven.Temp value 184.2 status UncertainLastUsableValue, source age 47 s
Upstream server unreachable; serving cached values with uncertain status
Tag quality degraded to uncertain; last good SourceTimestamp 2026-09-08T04:12:33ZConfirm the fix
Confirm the status returns to Good and that SourceTimestamp resumes advancing at roughly the sampling interval; then check that your aggregation reports reduced coverage for the affected window rather than a complete average.
Stop it happening again
Carry the status through the whole pipeline, alarm on uncertain duration rather than on value range, store quality alongside history so past windows can be excluded, and monitor the device or upstream connection status nodes directly.
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.