---
sourceDocument: Zurich ServiceNow AI Platform Capabilities
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/servicenow-platform

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Monitoring queues

# Monitoring queues in Instance Data Replication {#ariaid-title1}

* Release version: Zurich
* 
* Updated July 31, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Monitoring queues in Instance Data Replication

The Instance Data Replication (IDR) Queue Dashboard enables ServiceNow administrators with theadminoridradminrole to monitor replication queues and message processing across all replication sets.
This dashboard provides critical visibility into the status of replication records, message queues, and message processing to ensure data replication between instances is functioning effectively.
Show full answer Show less  

## Accessing the IDR Queue Dashboard

Navigate to **Instance Data Replication \> Queue Dashboard** to access the monitoring interface. The dashboard allows selection of time periods for analysis, either the last 24 hours (hourly data) or the last 5 days (daily data), and supports filtering by all replication sets or specific sets or tables.

## Key Features

* **IDR Queued Producer Records:** Displays hourly or daily counts of records queued per table. Helps identify which tables generate the most replication traffic and detect activity spikes that may cause performance lags on consumer instances.
* **Outbound Messages Remaining:** Shows the number of messages still in the replication queue waiting to be sent to the message queue. Persistent increases may indicate processing issues or that the instance is generating changes faster than they can be sent.
* **Outbound Messages Processed:** Tracks messages successfully produced and sent from the instance to the message queue. Comparing trends here with queued records helps detect if the instance is able to send data or if there are resource or connectivity problems.
* **Inbound Messages Remaining:** Displays messages waiting in the message queue to be processed by the consumer instance. Growing counts without resolution can signal consumer processing issues or data generation exceeding consumption capacity.
* **Inbound Messages Processed:** Shows the number of messages consumed by the instance over time for each replication set. Useful for identifying busy replication sets and analyzing processing trends.

## Practical Applications

* Identify replication lag and bottlenecks by monitoring spikes in queued records or message counts.
* Diagnose issues with producer or consumer jobs not running or connectivity problems with the message queue.
* Understand replication patterns and traffic distribution across tables and replication sets to optimize performance.
* Troubleshoot and maintain replication health proactively by tracking message flows and queue statuses.

## Additional Considerations

Use the dashboard's interactive charts to hover over data points for detailed counts and replication set or table names. You can exclude specific data sources from charts to focus on relevant metrics. This monitoring complements related tasks such as managing consumer access, deploying replication configurations, and resolving replication errors.  
Monitor the replication record queue, message produced queue, message consumed queue, and the messages processed for all replications sets through the Instance Data Replication (IDR) Queue Dashboard.

## Accessing the IDR Queue Dashboard {#idr-queue-dashboard__section_nhq_l3q_npb}

Users with the admin or idr_admin role can access the dashboard.

Access the IDR Queue Dashboard by navigating to Instance Data ReplicationQueue Dashboard.

## IDR Queue Dashboard {#idr-queue-dashboard__section_nnx_y3q_npb}

The IDR Queue Dashboard enables you to monitor the
following:

* IDR Queued Producer Records which are hourly records queued for all tables over a 24-hour time period.
* Outbound Messages Remaining which are messages remaining in the replication queue that are not yet sent to the message queue.
* Outbound Messages Processed which are messages produced from this instance to the message queue.
* Inbound Messages Remaining which are messages remaining in the message queue, that have not yet been processed.
* Inbound Messages Processed which are messages consumed on this instance.

{#idr-queue-dashboard__ul_uc5_fqz_spb}

In any chart, select Last 24 Hours or Last 5 Days as the time period. For the 24-hour period, the number of messages is per
hour. For the 5-day period, the number of messages is per day.

Select the legend link under the chart to exclude that data source.
Figure 1. IDR Queue Dashboard

## IDR Queued Producer Records {#idr-queue-dashboard__section_khy_1lq_npb}

With the IDR Queued Producer Records chart, you can see the
number of records queued for each table over an hourly or daily period. It shows which tables
account for the highest amount of traffic within IDR over
time. Use this chart to identify activity spikes that cause predictable performance lags on the
consumer instance.

For example, if you see that a large spike of activity occurs every day at 3:00 a.m. due to a
business rule on a table, you should expect a performance lag to occur on the consumer around
that time.

Select All Tables or a specific table. Position your cursor over a
point in the chart to see the queue count and tables for that point.

## Outbound Messages Remaining {#idr-queue-dashboard__section_cbp_xnq_npb}

With the Outbound Messages Remaining chart, you can determine whether a producer instance is
catching up to real-time replication after a large spike in activity.

When replication is working correctly, the messages remaining count should be very low. If
there is a spike in activity, you can expect a large value. For example, when a business rule is
changing tens of thousands of records within a minute.

You can also expect messages remaining to decrease over time as the jobs process the messages.  
If the messages remaining count continues to grow without resolution, it might indicate:

* An issue processing the messages. For example, the IDRProducerJob is not running, or cannot send messages to the message queue.
* The instance is recording changes faster than IDR can produce them.
{#idr-queue-dashboard__ul_tzt_jz4_ppb}

Select All Sets or a specific set. Position your cursor over a point in
the chart to see the message count and replication set name for that point.

## Outbound Messages Processed {#idr-queue-dashboard__section_tdd_l4q_npb}

With the Outbound Messages Processed chart, you can see the flow of records from a producer
instance to the message queue over time.

Trends for messages processed and the messages remaining over time indicates if replication is
recovering from a lag or if there are issues sending data to the message queue.  
Along with the Data Replication Queued Producer records chart, you can see if the instance is sending data. If your instance has queued records that are not being sent, it might indicate:

* The instance is not able to run the producer job. For example, due to other resource-intensive processes running on the instance and all worker threads being busy.
* There is an issue connecting to the message queue.
{#idr-queue-dashboard__ul_xn5_xz4_ppb}

To see the message count and replication set name for a graph point, select All Sets or a specific set and position your cursor over a point in the chart.

## Inbound Messages Remaining {#idr-queue-dashboard__section_rwp_g4q_npb}

With the Inbound Messages Remaining chart, you can determine whether a consumer instance is
catching up to real-time replication after a large spike in activity.

You can expect a temporary large value when there is a spike in activity. The value normally
decreases as the messages are processed.  
If this value continues to grow without resolution, it might indicate:

* An issue processing the messages. For example, the IDRConsumerJob is not running, or cannot read messages from the message queue.
* The instance is recording changes faster than IDR can consume them.
{#idr-queue-dashboard__ul_u3p_nz4_ppb}

Select All Sets or a specific set. Position your cursor over a point in
the chart to see the message count and replication set name for that point.

## Inbound Messages Processed {#idr-queue-dashboard__section_zwn_54q_npb}

With the Inbound Messages Processed chart, you can see the flow of records for each consumer
set over time.

Use the inbound messages chart to determine which replication sets have the most traffic and
see trends for messages processed and the messages remaining.

If the producer is sending records to the message queue and the consumer is not processing
them, it might indicate issues with the producer or the consumer instance.

Position your cursor over a point in the chart to see the message count and replication set
name for that point.
**Related concepts**   

* [Comparing replicated data between instances in Instance Data Replication](https://www.servicenow.com/docs/ZwBxZE8EjVPFz7VN4nDp_g "Find missing or mismatched records by comparing replication data between instances in Instance Data Replication (IDR).")
* [Deploying a replication configuration from one instance to another in Instance Data Replication](https://www.servicenow.com/docs/OdN3eTxiDLyQ~5NoJeDW2A "Copy a replication configuration from one instance to another through an update set in Instance Data Replication (IDR).")
* [Cloning options with Instance Data Replication](https://www.servicenow.com/docs/aWVqawl2PQx1R2Hy5XgOmA "Ensure that certain tables are preserved or excluded to clone your database from one instance to another successfully with Instance Data Replication (IDR).")
* [Monitoring replication status in Instance Data Replication](https://www.servicenow.com/docs/TXavyliYESfALYlb8NlXxA "Monitor the status of active producer and consumer replication sets, scheduled jobs, seeding requests, license usage, or scheduled replication through the Instance Data Replication (IDR) Monitoring Dashboard.")
* [Avoiding insert and update errors in Instance Data Replication](https://www.servicenow.com/docs/9jyxlc_h6j8A0f5itHT7Dg "You can avoid insert and update failures in Instance Data Replication (IDR) by specifying a class name filter in the producer replication set.")  
**Related tasks**   

* [Manage consumer access to replication data in Instance Data Replication](https://www.servicenow.com/docs/XOfuOuuug2GyvUFGjyMMpw "Approve a consumer's request to access replication data in Instance Data Replication (IDR).")  
**Related reference**   

* [Resolving data replication errors in Instance Data Replication](https://www.servicenow.com/docs/D6N4Ub9HnNCj5jQsdrOrmw "Resolve errors and monitor the status of Instance Data Replication (IDR) replication sets.")

*[\>]: and then