Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • IT Operations Management
Table of Contents
Choose your release version
    Home Orlando IT Operations Management IT Operations Management ITOM Health Event Management Manage and monitor alerts Alert correlation rules

    Alert correlation rules

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Alert correlation rules

    Alert correlation rules enable you to manually classify alerts into primary and secondary, and establish a relationship between them. Use alert correlation rules to group alerts that are related.

    For example, if a server in your organization goes offline, you do not need to see additional alerts that show that the virtual machines or applications running on the server are also down. Instead, these additional alerts, or secondary alerts, are grouped under the root alert called the primary alert. You can see these grouped alerts in the alert list in Alert Intelligence.

    Primary and secondary alerts

    • A primary alert identifies the root cause of an event.
    • A secondary alert is another alert that the same event generates, but is considered less important than the primary alert.
    The purpose of specifying secondary alerts is to identify which alerts to suppress, so you can reduce the amount of alert noise and focus on the primary alert. You are able to see both types of alerts, but the secondary alerts are grouped under the primary alert. You can see these groups in the alert list in Alert Intelligence.

    When working with alerts:

    • Secondary alerts remain open after a primary alert is closed in rule-based groups when the evt_mgmt.rule_based_manual_closure property is set to true.
    • The history of a secondary alert is retained after a primary alert is closed.
    • The alert management job runs even if the alert grouping job is not complete, if a specified time frame has passed. When this occurs, you can enable the Avoid INTs on secondary alerts rule to prevent incidents from being created for secondary alerts (when the evt_mgmt.avoid_int_enabled property is enabled), since an incident already exists for the primary alert.
    • By default, the Alert Group and Alert Management jobs run independently of each other. To avoid creating an incident on a secondary alert, set evt_mgmt.avoid_int_enabled = true, ensuring that the Alert Management job is executed after the Alert Group job is completed. Additionally, you must configure the Alert Management rule for Incident creation to filter out secondary alerts.
      Note: If the primary alert was not created when the Alert Management job started, an incident is created even if the alert becomes secondary during the next Alert Grouping job execution.

    How primary and secondary alert management rules work

    Primary and secondary alert management rules are simply filters that specify which kinds of alerts are classified as primary and which kinds are classified as secondary. The filter criteria runs against the Alert [em_alert] table.

    An alert can belong to more than one group, but only one level of secondary alerts is allowed under a primary alert. For example, if secondary alert A is grouped under secondary alert B, both alerts become secondary alerts under the same primary alert. See alert hierarchy for more information.

    Alert relationships

    Alert correlation rules enable you to specify what type of relationship the primary and secondary alerts must have for the rule to match. These relationships depend on the relationships between the CIs in the CMDB:
    • No Relationship: Ignore the relationship when looking for a match.
    • Same CI or Node: Relate both alerts with the same CI. If the CI field is blank, then the alerts must have the same Node value.
    • Primary is Parent: The relationship is in the direction of parent (primary) to child, as described in the CI Relationship Types table [cmdb_rel_ci]).
    • Primary is Child: The relationship is in the opposite direction, child (primary) to parent, as described in the CI Relationships table [cmdb_rel_ci]).

    When correlation rules run

    Alert correlation rules run when an alert is created or reopened. The alert is checked to determine if it matches being primary or secondary.

    When the primary alert severity is changed to Closed, the secondary alerts are also set to Closed unless they are part of other groups where the primary alert is not yet set to Closed.

    Alert hierarchy

    Only one level of secondary alerts is permitted. In situations where a secondary alert has its own secondary alert, the Event Management application flattens the hierarchy to preserve only two levels.

    For example, assume alert A is the primary alert and alert B is the secondary alert. If alert C becomes a secondary alert for alert B, the application flattens the hierarchy so that A remains the primary and B and C become sibling secondary alerts, one level below A.

    As another example, assume that there are three correlation rules that produce the following results:
    • Rule 1 (with an Order value of 1): B becomes a primary alert for A.
    • Rule 2 (with an Order value of 2): A becomes a primary alert for C and D.
    • Rule 3 (with an Order value of 3): E becomes a primary alert for A.

    When alerts B, C, D, and E are triggered, they all appear in the alert list separately because there are no correlations between them.

    When alert A is triggered:
    1. Rule 1 makes A a secondary alert under alert B.
    2. Rule 2 makes both C and D secondary alerts under alert A.
    3. Rule 3 makes A a secondary alert under E, giving alert A two primary alerts above it in the hierarchy.

    Therefore, if all alerts are triggered, only B and E appear in the alert list, indicated as primary alerts.

    Note: A secondary alert can be correlated with more than one primary alert, and vice versa.
    • Create an alert correlation rule

      Create an alert correlation rule to specify a primary alert and a related alert that is of secondary importance.

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Alert correlation rules

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Alert correlation rules

      Alert correlation rules enable you to manually classify alerts into primary and secondary, and establish a relationship between them. Use alert correlation rules to group alerts that are related.

      For example, if a server in your organization goes offline, you do not need to see additional alerts that show that the virtual machines or applications running on the server are also down. Instead, these additional alerts, or secondary alerts, are grouped under the root alert called the primary alert. You can see these grouped alerts in the alert list in Alert Intelligence.

      Primary and secondary alerts

      • A primary alert identifies the root cause of an event.
      • A secondary alert is another alert that the same event generates, but is considered less important than the primary alert.
      The purpose of specifying secondary alerts is to identify which alerts to suppress, so you can reduce the amount of alert noise and focus on the primary alert. You are able to see both types of alerts, but the secondary alerts are grouped under the primary alert. You can see these groups in the alert list in Alert Intelligence.

      When working with alerts:

      • Secondary alerts remain open after a primary alert is closed in rule-based groups when the evt_mgmt.rule_based_manual_closure property is set to true.
      • The history of a secondary alert is retained after a primary alert is closed.
      • The alert management job runs even if the alert grouping job is not complete, if a specified time frame has passed. When this occurs, you can enable the Avoid INTs on secondary alerts rule to prevent incidents from being created for secondary alerts (when the evt_mgmt.avoid_int_enabled property is enabled), since an incident already exists for the primary alert.
      • By default, the Alert Group and Alert Management jobs run independently of each other. To avoid creating an incident on a secondary alert, set evt_mgmt.avoid_int_enabled = true, ensuring that the Alert Management job is executed after the Alert Group job is completed. Additionally, you must configure the Alert Management rule for Incident creation to filter out secondary alerts.
        Note: If the primary alert was not created when the Alert Management job started, an incident is created even if the alert becomes secondary during the next Alert Grouping job execution.

      How primary and secondary alert management rules work

      Primary and secondary alert management rules are simply filters that specify which kinds of alerts are classified as primary and which kinds are classified as secondary. The filter criteria runs against the Alert [em_alert] table.

      An alert can belong to more than one group, but only one level of secondary alerts is allowed under a primary alert. For example, if secondary alert A is grouped under secondary alert B, both alerts become secondary alerts under the same primary alert. See alert hierarchy for more information.

      Alert relationships

      Alert correlation rules enable you to specify what type of relationship the primary and secondary alerts must have for the rule to match. These relationships depend on the relationships between the CIs in the CMDB:
      • No Relationship: Ignore the relationship when looking for a match.
      • Same CI or Node: Relate both alerts with the same CI. If the CI field is blank, then the alerts must have the same Node value.
      • Primary is Parent: The relationship is in the direction of parent (primary) to child, as described in the CI Relationship Types table [cmdb_rel_ci]).
      • Primary is Child: The relationship is in the opposite direction, child (primary) to parent, as described in the CI Relationships table [cmdb_rel_ci]).

      When correlation rules run

      Alert correlation rules run when an alert is created or reopened. The alert is checked to determine if it matches being primary or secondary.

      When the primary alert severity is changed to Closed, the secondary alerts are also set to Closed unless they are part of other groups where the primary alert is not yet set to Closed.

      Alert hierarchy

      Only one level of secondary alerts is permitted. In situations where a secondary alert has its own secondary alert, the Event Management application flattens the hierarchy to preserve only two levels.

      For example, assume alert A is the primary alert and alert B is the secondary alert. If alert C becomes a secondary alert for alert B, the application flattens the hierarchy so that A remains the primary and B and C become sibling secondary alerts, one level below A.

      As another example, assume that there are three correlation rules that produce the following results:
      • Rule 1 (with an Order value of 1): B becomes a primary alert for A.
      • Rule 2 (with an Order value of 2): A becomes a primary alert for C and D.
      • Rule 3 (with an Order value of 3): E becomes a primary alert for A.

      When alerts B, C, D, and E are triggered, they all appear in the alert list separately because there are no correlations between them.

      When alert A is triggered:
      1. Rule 1 makes A a secondary alert under alert B.
      2. Rule 2 makes both C and D secondary alerts under alert A.
      3. Rule 3 makes A a secondary alert under E, giving alert A two primary alerts above it in the hierarchy.

      Therefore, if all alerts are triggered, only B and E appear in the alert list, indicated as primary alerts.

      Note: A secondary alert can be correlated with more than one primary alert, and vice versa.
      • Create an alert correlation rule

        Create an alert correlation rule to specify a primary alert and a related alert that is of secondary importance.

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login