BadTooManyMonitoredItems

BadServer limits

What you actually see

CreateMonitoredItems succeeds for the first part of a large batch and returns this code for the remainder, so a subscription comes up with fewer items than configured.

Why it happens

• Per-subscription limit reachedServers advertise MaxMonitoredItemsPerSubscription in the ServerCapabilities object. Loading twenty thousand items onto one subscription because they all share a publishing interval will hit it. Some collectors default to a very large internal cap when the server advertises nothing, which hides the real limit until the server rejects the batch.
• Server-wide limit reached across all sessionsA separate total limit applies across every session. Your new collector can be well inside the per-subscription limit and still be refused because an HMI and a historian already hold most of the capacity. This is why the same configuration works in a test cell and fails in the plant.
• Subscribing to everything instead of what is neededAddress-space-wide subscription, generated from a browse of the whole server, produces tens of thousands of items of which a small fraction is ever consumed. Diagnostics nodes, string descriptions and static configuration values are frequently in there by accident.
• Duplicate items from several clients or several toolsEach client's items count separately. Three tools each monitoring the same two thousand tags is six thousand items on the server, with three times the sampling cost for identical data. Aggregation removes the duplication.
• Array elements expanded into individual itemsMonitoring each element of a large array with its own IndexRange creates one item per element. Monitoring the whole array as one item, or using a coarser IndexRange, replaces hundreds of items with one at the cost of transferring more per notification.

How to fix it

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

1. Read the advertised limits before you designBrowse the Server object to ServerCapabilities and read the maximum monitored items values it publishes. If the server advertises nothing or zero, treat the limit as unknown and probe it in a test by adding items in blocks until the rejection appears, then design to well under that.
2. Check the per-item results and account for the shortfallCreateMonitoredItems returns a status per item. Count the Good entries and compare against what you sent. A collector that ignores this comes up silently short, and the missing tags look like a data quality problem months later.
3. Split across subscriptions grouped by publishing intervalWhere the per-subscription limit is the constraint and the total is not, create several subscriptions at the same publishing interval and distribute items across them. Keep the number of distinct intervals small so you are adding subscriptions for capacity, not for rate.
4. Cut items that nobody readsWork back from the consumer. For availability, performance and quality figures you typically need a state or mode, a good-count, a reject-count and a cycle signal per machine, not every tag the PLC exposes. Removing unread items is the only change that reduces both item count and server CPU.
5. Apply deadband and DataChangeTrigger to cut load, knowing it will not cut countAn absolute deadband on a noisy analogue, or a Status-only DataChangeTrigger on a value you only need the quality of, removes notification traffic. The item still exists and still counts against the limit, so this is a throughput fix, not a capacity fix.
6. Aggregate duplicate consumersWhere several systems want the same tags, subscribe once with one collector and republish. This is usually the difference between fitting inside a PLC's limits and not.

Where it shows up, by tool and stack

What it looks like in the log

CreateMonitoredItems: 4096 of 12000 items created, remainder BadTooManyMonitoredItems
Server advertises MaxMonitoredItemsPerSubscription 4096; request exceeded limit
Subscription 2 item count 4096 at server maximum

Confirm the fix

Compare the configured item count with the count of Good results after creation and confirm they match, then confirm every expected tag is producing notifications rather than assuming the subscription is complete.

Stop it happening again

Design against the advertised ServerCapabilities values, make a configured-versus-confirmed item count check part of startup and alert on any mismatch, aggregate duplicate consumers, and keep the subscribed set driven by what the consumer needs.

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.