---
sourceDocument: Australia IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# DEX alert grouping

# DEX alert grouping {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 DEX Alert Grouping

DEX alert grouping is a mechanism in ServiceNow that consolidates multiple alerts triggered by the same DEX metric rule into a single alert group.
This reduces the number of individual alerts users must manage, streamlines incident response, and accelerates issue resolution.
Grouped alerts show a primary alert with a count of associated secondary alerts, simplifying alert monitoring and management.
Show full answer Show less  

## How DEX Alerts and Events Are Represented

* DEX events are identified in the **Events table \[emevent\]** with the Source field set to "DEX".
* Alerts generated from these events appear in the **Alerts table \[emalert\]** with the Source value as "DEX".
* The Metric name identifies alerts as either "DEX App Metric" or "DEX Device Metric".
* The Configuration item field indicates the related application or device.
* Alerts grouped by rules appear with the Group field value "Rules-based".

## Alert Correlation Rules

The **DEX Metric Correlation Rule** (configured under All \> Event Management \> Rules \> Alert Correlation Rules) controls when alerts should be grouped. Important points include:

* Only one alert is created per application and metric rule combination, regardless of the configuration item.
* Alerts are grouped if they share the same metric rule, even if they relate to different configuration items (devices or applications).
* Closing the primary alert in a group also closes all secondary alerts linked to it.

## Time-Based Alert Grouping

This feature groups alerts that occur within a specified time window, reducing alert noise for services that generate many alerts. Key details:

* The grouping time interval is configured in the **System Properties table \[sysproperties\]** via the property `sndex.alert.correlationrule.device.period`.
* The property value is set in seconds (e.g., 300 seconds for 5 minutes). Setting the value to 0 disables time-based grouping.

**Example:** If alert A1 is generated for metric rule R1 from device D1, and alerts A2 and A3 occur within 5 minutes for the same rule but different devices, A1 is the primary alert with A2 and A3 as secondary grouped alerts. If no alerts occur for 5 minutes, new alerts for the same rule form a new group with a new primary alert.

## Benefits for ServiceNow Customers

* Reduces alert overload by consolidating related alerts into manageable groups.
* Simplifies alert tracking and resolution by focusing on primary alerts representing groups.
* Speeds up incident response through clearer alert correlation and fewer disruptions.
* Allows customization of alert grouping intervals based on operational needs.  
When several alerts are triggered from events governed by the same metric rule in DEX, the alert grouping mechanism automatically consolidates them. This mechanism reduces the need for users to manage individual alerts, streamline their response process, and enable
faster issue resolution.

When alerts are grouped, you see the total count of secondary alerts grouped next to the primary alert number.

## DEX events and alerts representation {#alert-grouping__section_ndc_rw5_1bc}

In the Events table \[em_event\], any event with the Source field value as DEX is classified as a DEX event. For DEX, the Type field displays DEX Metric Rules as DEX alerts are generated based on DEX metric rules. When for any event, the State of the event is Processed, an alert is generated and saved in the Alerts table \[em_alert\].

In the Alerts table \[em_alert\], select any alert to access its details. An alert that is created from a DEX event, displays the Source field value as DEX. The Metric name field value appears as either DEX App Metric or DEX Device Metric. For an alert, the Metric name field value is DEX Device Metric. The Configuration item field shows the name of the corresponding application or device. For the alert whose corresponding
Group field shows Rules-based, are the DEX alert groups.

## Rule for alert correlation {#alert-grouping__section_qtg_zdv_1bc}

In AllEvent ManagementRulesAlert Correlation Rules, the DEX Metric Correlation Rule determines when alerts must be grouped and provides necessary details.  
Note:  
For one application and one metric rule, there's only one alert in DEX. DEX creates alert groups when the metric rule is the same, regardless of whether the configuration items are the same or different. When the problem is resolved, closing the primary alert also closes the secondary alerts within the same group.

## Time-based alert grouping {#alert-grouping__section_onq_tdv_1bc}

Time-based alert grouping automatically groups alerts according to predefined time intervals, which is advantageous for services generating numerous alerts. Consolidated alerts result in fewer disruptions for responders and contribute
to shorter resolution times.

In the System Properties table \[sys_properties\], the property sn_dex.alert.correlation_rule.device.period defines the time period in seconds for grouping and correlating similar metric rule-based DEX alerts. In the Value field, you can enter the desired time duration in seconds. For example, to set a 5-minute gap between alert groupings, enter 300. Entering 0
disables the rule.

Let's consider an example: Alert A1 is generated for rule R1 from device D1. After two minutes, alerts A2 and A3 are generated for the same rule R1, but from devices D2 and D3 respectively. With A1 being the first alert, it's
designated as the primary alert, and A2 and A3 are grouped as secondary alerts under A1.

Suppose you set the time duration to 300 seconds (5 minutes). If no alerts for rule R1 are generated within five minutes, alerts A4, A5, and A6 are generated for the same rule, a new group is formed. Alert A4 is set to the primary
alert, and A5 and A6 are grouped under A4.

However, if any alert is generated for rule R1 within five minutes, it's considered as a secondary alert to A1 and grouped accordingly.

*[\>]: and then