BadTooManySubscriptions

BadServer limits

What you actually see

CreateSubscription fails once a system has been running a while or once the last few clients are commissioned, while existing subscriptions keep working normally.

Why it happens

• One subscription per distinct publishing intervalA subscription has a single publishing interval, so every different rate you want needs its own subscription. Configuration generated per tag group, with intervals like 250, 300, 500 and 750 ms scattered across it, produces as many subscriptions as there are distinct values. Fifty rates means fifty subscriptions per client.
• Orphaned subscriptions from previous sessionsSubscriptions consume the limit until the server deletes them. Sessions that were abandoned rather than closed hold their subscriptions until the session timeout, then the subscription lifetime, elapses. A client that reconnects faster than that leaks a set of subscriptions on every cycle.
• Too many clients against a small embedded serverPLC and device servers are configured conservatively, often permitting only a small number of subscriptions in total across all sessions. Adding a second historian or a cloud collector to a PLC that already serves an HMI is enough to exhaust it.
• Client creating a subscription per monitored item or per tag groupSome integrations create a subscription per tag, per device or per screen. This scales linearly with the model and is the fastest way to exhaust any server. The correct unit is the publishing rate, not the logical grouping.
• Server limit deliberately low as admission controlMaxSubscriptionCount is a defence against resource exhaustion, and a well-configured server sets it to what it can genuinely serve. Hitting it is the server telling you your design exceeds its capacity, not a bug to be worked around.

How to fix it

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

1. Count your distinct publishing intervalsInventory the configuration and list the unique publishing intervals. Collapse them to a small standard set - for example 100 ms, 1 s and 10 s - chosen from what the consumer actually needs rather than from what the tag could theoretically deliver. This is usually a one-line change in a generator and removes most of the count.
2. Use per-item sampling intervals instead of extra subscriptionsYou do not need a subscription per rate. Put items on a common subscription and set each item's sampling interval individually; -1 makes an item inherit the subscription's publishing interval. That gives you per-item rates with one subscription.
3. Read the server's advertised limitsBrowse the ServerCapabilities object under the Server object and read the maximum subscription and monitored item properties the server publishes. Size your design against those numbers before commissioning rather than discovering them at go-live.
4. Close sessions properly and stop leakingCall CloseSession with deleteSubscriptions set on shutdown, and make sure abnormal exits are followed by a reconnect that transfers rather than recreates. Check the server's session and subscription diagnostics for entries that belong to clients that are no longer running.
5. Consolidate collectorsWhere several tools poll the same server, aggregate them behind one collector or gateway and distribute from there. One well-tuned session with three subscriptions is far cheaper for a PLC than five tools with their own connections.
6. Raise the server limit only after tuningIf the design is genuinely correct and the server is capable, increase MaxSubscriptionCount in the server configuration. Do this last: raising a limit on a device that cannot meet the load converts a clean rejection into missed samples and timeouts.

Where it shows up, by tool and stack

What it looks like in the log

CreateSubscription failed: BadTooManySubscriptions (existing 20, max 20)
Client requested 47 distinct publishing intervals; 47 subscriptions required
Subscription limit reached; rejecting request from session urn:collector:line3

Confirm the fix

Recount subscriptions per session after consolidation and confirm the total across all clients sits comfortably below the server's advertised maximum, with CreateSubscription succeeding and revised publishing intervals matching your standard set.

Stop it happening again

Standardise on a small fixed set of publishing intervals in whatever generates your configuration, use per-item sampling intervals for finer rates, size against the ServerCapabilities values at design time, and audit for orphaned sessions on a schedule.

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.