BadRequestTimeout
BadTimeouts
BadRequestTimeout means a single service call ran out of time. The RequestHeader carries a TimeoutHint and the server may abandon work that exceeds it. The usual causes are an oversized operation, a slow device behind the server, or a TimeoutHint left at an SDK default that is wrong for this server.
What you actually see
One kind of call - a large Browse, a bulk Read, a method that touches the field layer - times out consistently while small calls on the same session return instantly.
Why it happens
- The operation is genuinely too big for the time allowedReading several thousand nodes in one request, browsing a folder with tens of thousands of children, or resolving long browse paths on an embedded server takes real time. The server is not broken; the request is oversized for the hardware it is running on.
- The server is waiting on the device behind itA gateway or PLC-embedded server fetches values from the control layer or a fieldbus. If that layer is slow or unreachable the service call stalls. Per-item BadNoCommunication, BadNotConnected or BadDeviceFailure on the same nodes is the confirming signal.
- TimeoutHint set too low by the clientSDK defaults are chosen for responsive desktop use, not for a controller sharing a CPU with a scan cycle. A few seconds is fine for a Read of ten nodes and hopeless for a browse of a machine tool address space.
- Publish timeout shorter than the subscription can honourPublish is a long poll. Its timeout must exceed the publishing interval multiplied by the maximum keep-alive count, otherwise the client abandons its own Publish before the server was ever obliged to answer. This produces a steady drum of timeouts on a subscription that is behaving exactly as specified.
- Server under load or admission-controlledA loaded server queues work. Where it refuses outright you get BadServerTooBusy; where it accepts and cannot finish in time you get this. Check server diagnostics and host CPU during the failure window rather than only the client log.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Split the operation before raising any timerBatch Reads and Writes into chunks the server can answer quickly, and browse with MaxReferencesPerNode plus BrowseNext instead of asking for everything at once. Smaller requests are the fix; longer timeouts only hide the problem.
- Set TimeoutHint deliberately per operation classGive bulk browses and startup discovery a generous hint and keep interactive reads short. One global timeout across a fleet of mixed hardware guarantees it is wrong somewhere.
- Check the Publish arithmeticConfirm the Publish timeout comfortably exceeds publishing interval times maximum keep-alive count. A 1000 ms subscription with a keep-alive count of 10 needs more than 10 seconds of patience on a quiet subscription, not five.
- Look below the OPC UA serverRead a handful of the affected nodes individually. Per-item device codes tell you the delay is in the field layer, where no client tuning will help. That moves the work to the PLC or gateway configuration.
- Measure against a reference clientTime the same operation from UaExpert on the same network segment. If it is slow there too, the server or device is the constraint; if only your client is slow, look at your batching and your event loop.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | OperationTimeout in the configuration sets the default TimeoutHint and individual calls can override it. Raising it globally to mask one slow browse also delays detection of genuine faults everywhere else. |
| asyncua (Python) | The client's request timeout populates the header hint. Blocking work inside a coroutine delays response processing, so a request can appear to time out when the response actually arrived on time. |
| node-opcua | The client derives its Publish timeout from the subscription parameters, so changing the publishing interval or keep-alive count after creation without revisiting it produces exactly this fault. |
| Siemens S7-1500 | The integrated server shares the controller CPU with the control task. Wide browses and bulk reads compete with the scan cycle, so batch aggressively and browse once at startup rather than repeatedly. |
| KEPServerEX | The UA layer waits on the underlying device drivers. A timeout here usually maps to a device or channel that is slow or offline in the server's own configuration, visible in its event log. |
| UaExpert | Useful as a control experiment: perform the same read or browse from UaExpert on the same segment. It makes client-side batching problems obvious in a minute. |
What it looks like in the log
Read of 4000 nodes failed: BadRequestTimeout after 10000 ms
Publish request timed out before keep-alive was due (publishingInterval=1000, maxKeepAliveCount=10)
Browse of ns=4;s=MachineTool did not complete within the request timeout hintConfirm the fix
Re-run the same work in batches and confirm every batch returns Good well inside its TimeoutHint, and that the Publish channel produces regular keep-alives instead of timeouts.
Stop it happening again
Standardise batch sizes and per-operation timeouts in client configuration, derive Publish timeouts from the subscription parameters rather than hardcoding them, and browse once at commissioning instead of on every cycle.
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.