BadWaitingForInitialData

BadFirst value

What you actually see

Immediately after creating a subscription, the first notification for some or all items arrives with this status and no value, then real values follow a moment later.

Why it happens

• Normal startup transientA server always sends the first value when a monitored item is added, so that clients get an initial state without waiting a full publishing cycle. If the server has not yet sampled the source, that first notification carries this status instead of a value. This is by far the most common reason you will see it.
• Slow source that has not been polled yetWhere the server polls a device on its own cycle, an item created just after a poll waits nearly a full cycle for data. With a slow device scan or a long sampling interval, the waiting state can last noticeably longer than the publishing interval.
• Source that only produces on changeA value that is event-driven rather than polled may have no initial value at all until the source produces one. A rarely changing counter or a state that has not transitioned since server start can sit in this state for a long time legitimately.
• Underlying device not yet connected at server startIf the server started before the device was reachable, items created early wait for the first successful read. This resolves itself when the device connects, but a client that treats the status as fatal will already have given up.
• Item stuck in the waiting stateIf the status never clears, the source is not delivering at all and the item has effectively the same problem as an unconnected node. At that point it stops being a transient and needs the same diagnosis as a communication or configuration fault.

How to fix it

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

1. Wait before reactingGive the item at least a couple of sampling intervals plus one publishing interval before treating this as a problem. Client code that logs an error on the first notification will produce noise on every restart.
2. Treat the initial notification as state, not as dataThe server sends a first value for every item on creation. Design the client to accept a bad initial status, hold the item in a pending state and start processing when a Good value arrives, rather than pushing the bad status straight into the pipeline.
3. Check the sampling interval you actually gotThe server returns a revised sampling interval, which may be much slower than requested. A revised interval of several seconds explains a long wait. Log the revised values from CreateMonitoredItems rather than the requested ones.
4. If it persists, diagnose as a source problemAn item still waiting after many intervals is not waiting - it is not connected. Read the node directly outside the subscription. If a plain Read also fails, look at device communication and tag configuration.
5. Consider skipping the first value where it causes a stormOn a large subscription, thousands of initial values arrive at once. Where your pipeline does not need them, use the client's skip-first behaviour if it has one so the startup burst does not flood downstream systems.
6. Stagger client connects at scaleMany clients subscribing simultaneously 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.

Where it shows up, by tool and stack

What it looks like in the log

Initial notification for ns=2;s=Line1.Count: BadWaitingForInitialData
MonitoredItem created, revised sampling interval 1000 ms, awaiting first sample
Item still reporting waiting for initial data after 30 s

Confirm the fix

Watch the same 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

Design clients to expect a bad initial status on every monitored item, log the revised sampling and publishing intervals at startup, and stagger connects across a fleet so the initial-value 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.