---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Review integration and configuration health

# Review integration and configuration health {#ariaid-title1}

* Release version: Yokohama
* 
* Updated August 11, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read

Review your events to ensure alerts are created as intended. Start this process by checking the health status of your integration. This provides useful statistics to highlight where you can make improvements to enrich alerts
with relevant business context, group them for better noise reduction, escalate critical alerts promptly, and notify your team for swift response and resolution.

## Before you begin

Role required: evt_mgmt_operator or evt_mgmt_admin

## About this task

Health state metrics indicate how effectively alert automations add context and reduce noise, helping operators lower the Mean Time to Repair (MTTR). When adding a new integration, review these metrics, assess the rates, and
develop new rules to further enhance noise reduction and improve overall system performance.

## Procedure

1. Navigate to WorkspacesService Operations Workspace.
2. From the bottom of the navigation pane, select the AIOps configuration center icon ![ITOM AIOps configuration center icon]().  
   The ITOM AIOps configuration center page appears. The configuration center is a centralized workspace. Use it to configure and manage AIOps features from a single place.
3. In the Browse Integrations tab, select the All integrations drop-down list and select Pull or Push as required.
4. Select a pull, push, or a custom connector type tile.  
   If a pop-up menu opens, select the data to track from that connector and select Continue.
5. Select the Related events tab.  
6. In the Health state section, view the data for alerts and their associated attributes.  
   {#review-integration-config-health__table_ogg_3fw_mbc__entry__2}

   | Alert attribute | Description |
   |-|-|
   | Alert Suppression | The suppression ratio indicates the proportion of alerts created to events received. Reducing unwanted alerts can be achieved by de-duplicating or ignoring them. * De-duplication: The message_key field is a unique identifier for an alert in the source monitoring system. It is used for de-duplication and alert flapping detection purposes. If the source event does not provide reliable unique values, you can use the default value or create your own. If the message key is not defined, the default message key will be \<Source + Node + Type + Resource + Metric Name\>. The guideline is for the event source to automatically populate the \<Source + Node + Type + Resource + Metric Name\> fields and generate the message key. This practice facilitates better distribution of event processing across instance workers and nodes. If the source event does not provide values for these fields, ensure they are populated using transform rules. This action, which does not impact event processing, is essential for de-duplication. Populate as many of these fields as possible before sending the event to the instance. Doing so enhances the distribution of events across processor workers, resulting in improved throughput and scalability. To learn more about de-duplication, see [Event Management configuration preferences](https://servicenow-prod.fluidtopics.net/WX5uB5nhCpuS1TthTDtUZQ "Preferred settings of properties and general configuration."). To set the message key in your custom connector integration, see [Configure a custom connector](https://servicenow-prod.fluidtopics.net/IdOtU1tZnwOk6a~agH_uDA "Authenticate your custom connector as a data source to enable the pushing of event information to your ServiceNow instance. Define the custom connector by providing its details and mapping fields. This allows the extracted information from your custom connector's event messages to populate the required event fields. Finally, create and supply a URL for the custom connector webhook."). * Ignore alert event rules: Filter out low-quality alerts by creating an [ignore automation](https://servicenow-prod.fluidtopics.net/17kbFiB1ZOKvM1Bkr7vHtg "Ignore automation streamlines the process of disregarding irrelevant or false-positive alerts from monitoring systems, efficiently managing alert fatigue by filtering out unnecessary notifications. This allows teams to focus on critical issues."). {#review-integration-config-health__ul_osy_s5h_4bc} |
   | Alert compression rate | When you group alerts, a high compression rate is desirable because it means fewer alerts remain for your operations team to review and act on. This can lead to improved team efficiency. The compression rate is calculated as 1 -- (the number of alert groups + the number of ungrouped alerts) / total alerts. To learn about alert aggregation, see [Alert grouping](https://servicenow-prod.fluidtopics.net/UWgNOxLiJOfWJypoHuIMjg "Alert grouping is the process of organizing and consolidating related alerts into sets based on common characteristics or criteria. This helps in simplifying alert management by reducing noise, making it easier to prioritize, track, and address issues efficiently. Grouped alerts provide a clearer overview of related incidents, facilitating quicker root cause analysis and remediation."). One way to improve your alert compression rate is by defining a new grouping automation. |
   | CI Binding | The percentage of alerts successfully bound to a Configuration Item (CI) in your CMDB is crucial. Aim for this number to be at or near 100% to enhance alert grouping, root cause analysis, assignment, and more. To bind a host, machine, or any device with an IP, populate the Node field with a unique hostname, FQDN, IP, or MAC address. This can be done within the integration itself or by creating an enrich automation. For more complex scenarios, you can override node-based binding using event rules. For more information on CI binding, see [Binding alerts to CIs](https://servicenow-prod.fluidtopics.net/yhAevCrJwBxWNoZGxoo2EQ "CI binding or linking is the process of finding and connecting a Configuration Item (CI) from the Configuration Management Database (CMDB) to an alert, using the logic defined in event rules. This helps ensure alerts are tied to the right IT components for better visibility and faster issue resolution."). |
   | Metric name configured | Shows the percentage of alerts that have a metric name defined. It's crucial to aim for near 100% because it's used by default in our automated correlation algorithm. This can be achieved within the integration itself or by creating an [enrich automation](https://servicenow-prod.fluidtopics.net/ctyrBPWC1XN3_jZU06vyJQ "Alert enrichment involves transforming raw events from monitoring tools into a standard format, aiding automated grouping and response. This includes extracting fields from lengthy alert payloads or composing them into a standardized format. Additionally, you can create tags, which are metadata added to alerts for easier filtering and grouping."). |
   | Suggested tags | Provides suggested alert tags based on the integration payload. Alert tags are structured fields that you can define to facilitate easier filtering and grouping of alerts. The tags are stored in sn_itom_integ_app_recommendation_tags_suggestion, and only the top 5 most popular tags are displayed. In case you prefer to refine the results of suggestion mechanism, you can use property sn_itom_integ_app.evt_mgmt_tag_suggestion_ignore_keys, which displays a list of lowercase field names or keywords, separated by commas, to be ignored when scanning additional alert info for tag suggestions. Default value is time. |
   [Table 1. Alert attributes]

   {#review-integration-config-health__table_ogg_3fw_mbc}
7. In the Events section, ensure that your events are generating alerts as expected.  
   Verify that alert fields and tags are populated correctly to make the alerts easier to read and filter in Express List. Confirm that severity values align with your operations team's expectations and that fields and tags follow a standardized format across sources for easier grouping.

   By verifying alert generation, you can be confident that your system is properly configured to detect and notify you of noteworthy occurrences. For information on the fields in the Events section, see [Integration and configuration health event fields](https://servicenow-prod.fluidtopics.net/YpU6wQj85JlpLewWlbeHkA "Populate the event fields to capture details such as the event time, description, alert number, state, severity, metric name, node, message key, and error message, enabling precise tracking, effective incident management, and improved error analysis.").
{#review-integration-config-health__steps_srm_zfk_5wb}

## What to do next

Now that you've confirmed alerts from the events, you can initiate the alert automation process by selecting Add automation. This takes you to the ignore automation step, where you can disregard
irrelevant or false-positive alerts. Following that, proceed to enrich, group, and automate responses. This process involves transforming raw alerts into a format understandable by ServiceNow, grouping the alerts, and escalating an alert to ensure an immediate response from the appropriate team or individual. For more information on alert automation, see [Alert automation in Service Operations Workspace for ITOM](https://servicenow-prod.fluidtopics.net/_Watdnuz_THpJ_zuLKvRYg "Alert automation is crucial as organizations deal with increasing number of alerts and complex IT infrastructures. Manual alert handling is slow, error-prone and inefficient, underscoring the need for automated systems. Automation can improve the mean time to resolve alerts, improve service reliability and better scale staff resources.").

*[\>]: and then