UncertainInitialValue

UncertainFirst value

What you actually see

The first notification for many items after a subscription is created carries this status, and real values with Good status follow within a cycle or two.

Why it happens

• Normal startup, before the first sampleA server always sends a first value when a monitored item is created so the client has an initial state without waiting a full publishing cycle. Where the source has not yet been sampled, that first value is an unconfirmed initial value with this status. This is by far the most common reason you see it.
• Server restarted and has not polled everything yetAfter a restart the server's cache is empty and repopulates over one or more scan cycles. Items whose source has not been reached yet report their initial value. On a large address space with a slow device scan this window can last noticeably longer than you would expect.
• Event-driven value that has not changed since startA value that is only updated when the source produces a change may have nothing to confirm for a long time. A state that has not transitioned or a counter that has not incremented since server start can legitimately sit in this status.
• Device not reachable at server startIf the server came up before the device, items created early hold an unconfirmed initial value until the first successful read. This resolves itself when the device appears, but a client that treats the status as fatal will already have failed.
• Item stuck because the source never deliversA status that never clears is no longer a startup transient - the source is not delivering at all. At that point it needs the same diagnosis as an unreachable node, and the value you are looking at is a default that has never been true.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Expect it and hold the item pendingDesign the client so the initial notification is treated as state rather than as data. Hold the item in a pending state and start processing when a Good value arrives. Code that pushes the initial value into the pipeline injects a default into your data set on every restart.
2. Wait a bounded number of intervals before alarmingAllow a couple of sampling intervals plus one publishing interval before treating it as a problem. Use the revised sampling interval the server returned, not the one you requested, because a revised value of several seconds changes what a reasonable wait is.
3. Consider skipping the first value on large subscriptionsOn a subscription with thousands of items the initial values all arrive at once. Where your pipeline does not need them, use your collector's skip-first option so the startup burst does not flood downstream systems with unconfirmed values.
4. If it persists, diagnose as a source problemRead the node directly outside the subscription. If a plain Read also returns an unconfirmed or bad status, the item is not waiting - it is disconnected, and the investigation moves to device communication and tag configuration.
5. Stagger client connects across a fleetMany clients subscribing at once multiply the initial-value burst and the first-sample load on the server. Staggering connects is the most effective client-side measure against startup storms and shortens the window in which this status appears.

Where it shows up, by tool and stack

What it looks like in the log

Initial notification for ns=2;s=Line1.Count: UncertainInitialValue
MonitoredItem created, revised sampling interval 1000 ms, awaiting first confirmed sample
Item still reporting an unconfirmed initial value after 60 s

Confirm the fix

Watch the item for a few publishing cycles and confirm it transitions to Good with a real SourceTimestamp; if it never transitions, read the node directly to separate a subscription problem from a source problem.

Stop it happening again

Treat the first notification as pending state in every client, log the revised sampling and publishing intervals at startup, use skip-first on large subscriptions, and stagger connects so the burst does not arrive from every client at once.

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.