--- sourceDocument: Zurich IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/it-operations-management Release : - zurich ft:locale : - en-US ft:publication_title : - Zurich IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # ECC queue for Discovery # The ECC queue for Discovery {#ariaid-title1} * Release version: Zurich * * Updated March 24, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 The ECC queue for Discovery The External Communication Channel (ECC) Queue in ServiceNow acts as a communication link between your ServiceNow instance and external systems, primarily the MID Server, during IT Asset Discovery. It holds records of messages exchanged throughout all discovery stages, capturing both outgoing requests (output) and incoming responses (input) related to discovery probes and sensors. Show full answer Show less ## Key Features * **ECC Queue Records:** Each record represents a message in the discovery process with XML payloads detailing probe and sensor activities, enabling tracking of targeted assets and discovery progress. * **Automatic Deletion:** To manage storage, ECC queue records older than 7 days are deleted automatically by default. Customers can adjust this retention period and set table rotation schedules for *eccqueueevent* and *eccqueue* tables to keep data longer, which is useful for troubleshooting discovery issues. * **Access Points:** Customers can view ECC queue records via Discovery \> Output and Artifacts \> ECC Queue or ECC \> Queue, providing transparency into probe instructions and returned data. * **Record States:** ECC queue messages transition through states such as ready, processing, processed, and error, reflecting the lifecycle of discovery tasks. Monitoring these states helps identify and troubleshoot failed discovery activities. * **Debugging Support:** Customers can use script debuggers to analyze business rules and code processing ECC queue payloads, aiding in advanced troubleshooting. * **Configurable Properties:** A key property allows preservation of ECC queue attachments instead of automatic deletion upon successful sensor processing, which is beneficial for debugging purposes. This can be managed under Discovery Definition \> Properties. ## Key Outcomes By effectively managing and monitoring the ECC queue, ServiceNow customers can ensure smooth and transparent discovery operations. Retaining ECC queue data for a suitable period supports in-depth troubleshooting and analysis of discovery failures or incomplete asset data collection. Understanding ECC queue states and leveraging debug capabilities enable faster resolution of issues, improving the reliability and accuracy of IT Asset Discovery processes. The External Communication Channel (ECC) Queue is a connection point between your ServiceNow instance and other systems that integrate with it, most commonly a MID Server.{#r_DiscoveryStatusECCQueue__ph_ecc-queue-intro} ## Contents of the ECC Queue {#r_DiscoveryStatusECCQueue__section_cjh_4cr_ccb} The ECC queue contains records that are created during all stages of discovery. Each record is a message from the instance to system your are targeting for discovery, classified as output, or a message from that system to the instance, classified as input. {#r_DiscoveryStatusECCQueue__p_ecc-queue-content} ECC queue records provide you with a connected flow of probe and sensor activity along with the XML payload sent to or from an instance and the assets you're targeting. ## Automatic deletion of ECC queue records {#r_DiscoveryStatusECCQueue__section_z4h_4cr_ccb} As your IT Asset Discovery runs, the size of the ECC queue can grow to several gigabytes. Most of the "completed tasks" records are unnecessary, but some might be important for issue resolution. For example, if Discovery is not properly capturing the disk drives on a particular Windows server, you can look in the ECC Queue at the data returned by the Windows - System Information probe. For this reason, you should retain ECC Queue data from Discovery for at least a month. By default, records in the ECC Queue older than 7 days are deleted automatically. You can set the deletion schedule by updating the ECC queue (as we will explain in the next section) and the table rotation schedule. The table rotation names are: * ecc_queue_event * ecc_queue {#r_DiscoveryStatusECCQueue__ul_jx3_5cr_ccb} ## Accessing the ECC queue {#r_DiscoveryStatusECCQueue__section_djh_4cr_ccb} You can access the ECC queue from either of these locations: * DiscoveryOutput and ArtifactsECC Queue * ECCQueue {#r_DiscoveryStatusECCQueue__ul_nj3_gfp_qbb} The following image is an example of a record in the ECC queue. This record shows that a ConnectorProbe was instructed to run and has been processed. Note the XML payload it returned as the discovery task collected data. See [The MID Server ECC queue](https://www.servicenow.com/docs/access?context=ecc-queue-mid-server&version=zurich&pubname=zurich-servicenow-platform&ft:locale=en-US) for a description of each field. Figure 1. An example ECC queue record ## ECC queue states Input and output messages keep processing until the discovery is finished or terminated. You can monitor the ECC queue to see records populate during discovery and see the states of each record change. ECC queue input records are processed by business rules (BR), but not all business rules direct these ECC queue inputs to process. As a result, some ECC queue inputs remain in a ready state. The process is as follows: 1. When new probe instructions are available for the MID Server, the system creates an output record with the state of ready. 2. The MID Server then starts processing the probe instructions and the state changes to processing before it finally changes to processed. 3. When a result returns to the MID Server and is ready to be sent to the instance, the system creates an input record with the state of ready. 4. While the system processes the payload, the state changes to processing before it finally changes to processed. If any errors are encountered, the state changes to error. You can review errors as a starting point for troubleshooting a failed discovery. {#r_DiscoveryStatusECCQueue__ol_gww_ls4_lz} ## Debug processing of ECC queue records {#r_DiscoveryStatusECCQueue__section_exh_c3r_pvb} To use a script debugger, process the payload on the same session as the debugger. Review the business rule which processes the particular ECC queue record and the actual code which processes the payload. ## Properties and parameters that affect the ECC queue These properties are available to control aspects of the ECC queue:{#r_DiscoveryStatusECCQueue__table_khy_354_lz__entry__2} | Property | Description | |-|-| | Save ECC queue attachments | The normal behavior for Discovery sensors is to delete attachments to ECC queue entries on successful sensor processing. Enabling this property overrides this behavior, and forces attachments to be preserved. This is typically done for debugging purposes. To enable this property, navigate to Discovery DefinitionProperties. | [ ] {#r_DiscoveryStatusECCQueue__table_khy_354_lz} **Related topics** * [Manage ECC Queue content for a MID Server](https://www.servicenow.com/docs/access?context=ecc-queue-mid-server&version=zurich&pubname=zurich-servicenow-platform§ion=manage-ecc-queue-content&ft:locale=en-US) *[\>]: and then