A Monitored Item is the fundamental sampling unit within an OPC UA Subscription. It is created by a Client to instruct the Server to observe a specific Node Attribute—typically the Value attribute of a Variable Node—at a defined sampling interval. Crucially, the Monitored Item also specifies a Monitoring Filter, such as a Deadband Filter, which determines the conditions under which a change in the attribute's state triggers the generation of a Notification Message for delivery to the Client.
Glossary
Monitored Item

What is a Monitored Item?
A Monitored Item is a client-defined entity within an OPC UA Subscription that specifies a particular Node attribute to watch and the criteria for generating a Notification Message.
This mechanism decouples the sampling rate from the notification rate, dramatically reducing network overhead compared to cyclic polling. The Server monitors the attribute in its internal real-time data system, applying the filter to suppress inconsequential fluctuations. Only when the filter criteria are met is a notification queued for transmission within the next Publish Response, ensuring efficient, event-driven data flow for supervisory control and data acquisition.
Key Parameters of a Monitored Item
A Monitored Item is defined by a set of parameters that specify what to watch and when to notify. These settings control the sampling rate, filtering criteria, and delivery semantics for data change notifications within a Subscription.
Sampling Interval
Defines the rate at which the Server samples the underlying data source for the Monitored Item.
- Fastest practical rate: -1, meaning the Server samples at its maximum capability.
- Explicit rate: A positive integer in milliseconds (e.g.,
100for 10 Hz). - 0 value: Inherits the Subscription's publishing interval.
- Key behavior: A faster sampling interval increases CPU load but reduces the risk of missing transient signal changes between publish cycles.
Queue Size
Specifies the depth of the notification queue for this Monitored Item before overflow behavior occurs.
- Default of 1: Only the most recent notification is queued; older unsent notifications are discarded.
- Larger values: Buffer multiple changes for delivery in the next Publish response.
- Discard policy: When the queue is full, the Server either discards the oldest notification (DiscardOldest) or the newest (DiscardNewest).
- Use case: Set >1 for high-frequency signals where every transition must be logged, even during network congestion.
Data Change Filter
An optional filter that suppresses notifications unless the data change meets specific criteria, reducing network traffic.
- Deadband Filter: Suppresses notifications unless the absolute change in a numeric value exceeds a defined threshold. Types include:
- Absolute Deadband: Triggers on a fixed engineering unit change (e.g., ±0.5°C).
- Percent Deadband: Triggers on a percentage of the EURange.
- Status Change Filter: Triggers only when the StatusCode quality bits change (e.g., from Good to Uncertain).
- No filter: Every detected change generates a notification.
Monitoring Mode
Controls the operational state of the Monitored Item and how it interacts with the Server's sampling engine.
- Disabled: The item is defined but not actively monitored. No sampling occurs.
- Sampling: The Server samples the value but does not generate notifications. Useful for pre-warming caches.
- Reporting: Full operation—the Server samples, evaluates filters, and queues notifications.
- Lifecycle: Clients can dynamically toggle modes to pause and resume monitoring without deleting and recreating the item.
Attribute ID & Index Range
Identifies the specific Node attribute to monitor and, for array values, a subset of elements.
- Attribute ID: The numeric identifier of the attribute (e.g.,
13for the Value attribute,14for SourceTimestamp). - Index Range: A string specifying a subset of an array value (e.g.,
"0:4"to monitor only the first five elements). - Scalar vs. Array: Monitoring a scalar attribute is straightforward; monitoring an array attribute without an Index Range triggers on any element change.
- Practical use: Monitor only a critical element of a large array to minimize processing overhead.
Discard Policy
Determines which notification is discarded when the Monitored Item's queue overflows.
- DiscardOldest: Removes the earliest queued notification to make room for the newest. Best for applications that prioritize the most current state.
- DiscardNewest: Removes the most recent notification, preserving the historical sequence. Best for applications that must not lose any transitions.
- Interaction with Queue Size: A Queue Size of 1 with DiscardOldest means only the latest value is ever queued—ideal for dashboard displays.
- Configuration: Set per Monitored Item, allowing different policies for different signals within the same Subscription.
Frequently Asked Questions
A Monitored Item is the fundamental unit of data surveillance in OPC UA. These FAQs dissect the mechanics of sampling intervals, queue depths, and filter criteria that determine how and when a client receives change notifications from the server's address space.
A Monitored Item is a client-defined entity within an OPC UA Subscription that specifies a particular Node Attribute to watch and the precise criteria for generating a Notification Message. It acts as a configurable probe inserted into the server's address space. The server's subscription component samples the designated attribute—typically the Value attribute of a Variable Node—at a client-defined Sampling Interval. If the sampled value or status meets the configured filter criteria (e.g., a Deadband Filter), the server creates a notification and places it into the subscription's delivery queue. This mechanism eliminates inefficient client polling, as data flows from server to client only when a meaningful change is detected. Each Monitored Item is uniquely identified by a ClientHandle and a server-assigned MonitoredItemId, allowing precise correlation of incoming notifications to their originating configuration.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Monitored Item vs. Subscription vs. Node
Distinguishing the three core entities involved in OPC UA data monitoring and their distinct roles in the client-server architecture.
| Feature | Monitored Item | Subscription | Node |
|---|---|---|---|
Definition | Client-defined entity specifying a Node attribute to watch and notification criteria | Client-managed object grouping Monitored Items and controlling notification pacing | Fundamental atomic unit in the Server's Address Space with attributes and references |
Primary Location | Exists within a Subscription on the Client side | Exists within a Session on the Client side | Exists within the Address Space on the Server side |
Core Function | Defines what to watch and when to report | Controls how and when notifications are delivered | Represents the actual data source, object, or method |
Lifecycle Management | Created and deleted by the Client via the Subscription | Created and deleted by the Client via the Session | Managed by the Server; created and deleted via NodeManagement services |
Sampling Interval | Configurable per-item; determines rate Server checks the value | Not applicable; inherits pacing from Publishing Interval | Not applicable; Node is a passive data structure |
Filtering Capability | |||
Notification Trigger | Value change exceeding Deadband, or StatusCode change | Publishing Interval timer expires | Not applicable; Node does not initiate communication |
Relationship | References exactly one Node attribute | Contains zero or more Monitored Items | Referenced by zero or more Monitored Items |
Related Terms
Understanding a Monitored Item requires context on the surrounding OPC UA services and objects that govern data subscriptions, filtering, and notification delivery.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us