How to Fix OPC UA BadTooManyMonitoredItems
You are adding monitored items to a subscription and partway through the server starts rejecting them with BadTooManyMonitoredItems. The connection is fine and earlier items work, so this is a capacity limit, not a fault. This page shows how to find which limit you hit - per subscription, per session, or per server - and how to redistribute the load so all your points get monitored without exceeding the ceiling.
Fix OPC UA BadTooManyMonitoredItems in one line: BadTooManyMonitoredItems means the OPC UA server refused a new monitored item because a configured maximum was reached. The limit can be per subscription, per session, or server-wide. Fix it by finding which ceiling you hit, then spreading items across more subscriptions or sessions, raising the server limit if you administer it, or cutting items you do not need.
Identify Which Limit You Hit
Servers enforce several separate caps: a maximum number of monitored items per subscription, a maximum per session, and a global maximum across the whole server. The status code is the same for all three, so the first job is to work out which one bit. Note how many items you had successfully created when the rejection started - that count is the ceiling you are up against.
Test which scope by adding a fresh subscription in the same session and trying to place items there. If the new subscription accepts items, your limit was per subscription; if it also rejects immediately, the ceiling is per session or server-wide. This one experiment usually tells you where to push. Keep track of your total item count as you go so the ceiling is a number, not a guess.
Spread Items Across More Subscriptions or Sessions
If the cap is per subscription, split your points across several subscriptions inside the same session. This is often the simplest fix and has a side benefit: you can give each subscription its own publishing interval, so fast points and slow points no longer share one cadence. Group by required update rate while you are at it.
If the cap is per session, open a second session. Fewer clients do this cleanly, but it is legitimate and sometimes necessary against a server with a tight per-session ceiling. Weigh it against server load, because each session and subscription costs the server resources - see how the cadence you choose affects that in setting OPC UA sampling and publishing intervals.
Cut the Item Count You Actually Need
Before you scale sessions, question the item list. Large subscriptions often carry points nobody uses: duplicated tags, diagnostic nodes subscribed by mistake, or high-rate items that only need a trend. Every item you remove is one you never have to spread. Reviewing the list against what the client genuinely consumes frequently gets you back under the ceiling with no architecture change.
Consolidation helps too. If you are monitoring many child nodes of one object individually, check whether the server exposes an aggregate or a single node that carries what you need. Understanding how the address space is structured makes this easier; see the OPC UA address space information model.
Raise the Server Limit Only If You Own It
If you administer the server, the caps are configurable, and raising a per-subscription or per-session maximum may be the correct fix - provided the hardware can carry the load. Do not raise a limit blindly: the cap usually exists because the server was sized for it, and pushing past it can degrade every client, not just yours. Raise it in step with a check on server CPU and memory headroom.
On a remote gateway you often do not own the server, so you cannot change its limits and must live within them by spreading load. Document the exact ceiling you found and the item count you need, and hand that to whoever administers the server if a limit increase is genuinely warranted.
Verify the Fix
After redistributing, recreate every monitored item and confirm they all report - no lingering BadTooManyMonitoredItems, and each point shows live data with good quality. Count the successfully created items and confirm the total matches what you intended to monitor. A silent shortfall means some items failed and you missed it.
Then confirm the server is stable under the new layout. Splitting into more subscriptions or sessions adds server overhead, so watch that publishes keep arriving on time and the server is not now struggling. A fix that trades a rejection for a slow server is only half a fix.
Common Mistakes
The main mistake is treating BadTooManyMonitoredItems as a bug to retry rather than a limit to design around - retrying the same over-full subscription just fails again. The second is raising a server limit you do not understand and overloading the box for every client.
Another is splitting into many tiny subscriptions without grouping by update rate, which multiplies overhead for no benefit. Group fast points together and slow points together. And do not forget to prune: shedding unused items is the cheapest fix and the one people skip because scaling feels more decisive.
Frequently Asked Questions
What causes BadTooManyMonitoredItems in OPC UA?
The server refused a new monitored item because a configured maximum was reached - per subscription, per session, or server-wide. It is a capacity limit, not a connection fault, which is why earlier items work and only new ones are rejected. Find which ceiling you hit by trying items in a fresh subscription, then a fresh session.
How do I fit more monitored items past the server limit?
Spread items across more subscriptions if the cap is per subscription, or additional sessions if it is per session, grouping points by required update rate. Prune unused or duplicate items first, since that is the cheapest fix. Raise the server's own limit only if you administer it and the hardware has headroom.
Does adding another subscription always help?
Only if the limit is per subscription. Test by creating a new subscription in the same session and trying to add items there. If they succeed, the cap was per subscription. If they are rejected immediately, the ceiling is per session or server-wide, and you need another session or a server-side limit change.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- OPC Unified Architecture Specification (IEC 62541) - OPC Foundation
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.