---
sourceDocument: Australia IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/it-operations-management

 Release :

    - australia

ft:locale :

    - de-DE

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# About events and alerts in ITOM AIOps

# About events and
alerts
in ITOM AIOps {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 Minuten Lesedauer

Learn the difference between events and alerts, and alert types and statuses.

Whenever an issue occurs on your network, such as a computer going down or a database failure, the event monitoring tools send events to your ServiceNow instance. The Event Management application then processes the events and generates alerts to indicate that an action must be taken to resolve the issue.

## Events and alerts {#about-alerts__section_mpd_jgh_1bc}

An event is a change or occurrence in the normal operations of a service, API, system network, process, or workflow. Events can be triggered by manual input, such as pressing
a button, or they can be generated automatically. They can be pulled (observed) or pushed (logged) to a system for tracking. Use event data to track system changes over time and trigger logic to escalate an event to an alert if a
specified performance threshold is breached.
Event Management generates alerts based on event
rules.

An alert is
something that needs your attention but doesn't necessarily require an immediate response. Events that meet or exceed a defined condition or threshold to indicate they require immediate attention or action trigger
alerts.
As events occur Event Management generates alerts, applies alert management rules, and prioritizes alerts for remediation and root cause analysis.

## Alert states {#about-alerts__section_kht_5kh_1bc}

There are four alert states, each of which have different execution flows and associated code.

* Open - The first stage in the processing of an alert.
* Closed - Closing an alert also closes any related incident that is not already resolved or closed.
* Reopen - When events are generated that are related to an existing closed alert, the alert is reopened. Alerts can also be reopened manually.
* Flapping - Flapping is a state when multiple open-close events are generated in rapid succession for an associated closed alert.
{#about-alerts__ul_mql_blh_1bc}

## Alert priority and severity {#about-alerts__section_vvg_2pp_y1c}

The two most common characteristics of an alert are the priority and the severity.

* For better triage and focus, alerts that have a higher priority are brought to the top of the alert list. This placement brings to your attention those alerts that require you to handle them at a higher priority than other alerts. The priority of an alert helps you determine how important the impact is to application services. Your Event Management administrator configures the algorithm used to calculate priority.
* The Severity of an alert indicates how serious the underlying issue is. The following table lists the default severities. {#about-alerts__table_egv_c31_gdb__entry__2}

  | Severity | Description |
  |-|-|
  | ![Resource icon]() Critical | The resource is either not functional or critical problems are imminent. |
  | ![Functionality icon]() Major | Major functionality is severely impaired or performance has degraded. |
  | ![Minor icon]() Minor | Partial non-critical loss of functionality or performance degradation occurred. |
  | ![Warning icon]() Warning | Attention is required even though the resource is still functional. |
  | ![OK icon]() OK | An informational message that an alert is created. The resource is still functional. No action required. |
  | ![Clear icon]() Clear | The alert no longer needs action. |
  [ ]

  {#about-alerts__table_egv_c31_gdb}
{#about-alerts__ul_jsq_3f1_gdb}

You can view the severities on the Service Operations Workspace dashboard.

## Alert types and correlated alerts {#about-alerts__section_emk_tzz_fdb}

Alerts are often related, or
correlated, to
each other. For example, if a router goes down, several separate alerts could be generated, one for each server connected to the router. Event Management can group alerts automatically based on specified correlation rules, with one primary root alert at the top and secondary alerts under the primary alert. You can choose to suppress secondary alerts to
reduce the amount of alert noise and focus on the primary alert. You can also group alerts manually. In addition, you
can manually attach additional alerts to a primary alert.

In the following example, if a router goes down on your network, network communication is also affected for connected servers, assuming they can't reach any other routers. The router outage becomes the primary alert and the alerts
generated on the server are secondary alerts correlated under the router alert.  
Abbildung : 1. Secondary alert generation

To learn more about the correlation types, see [Alert grouping types and creation methods](https://servicenow-prod.fluidtopics.net/WEtpW1u6XYoBpG8YakJ0VQ "Explore different alert grouping types, understand their descriptions, and learn about their creation methods to enhance problem identification and streamline alert management.").

## Alert flapping {#about-alerts__section_nz4_k5x_hdb}

An alert can flap, meaning that it gets multiple open-close events in rapid succession. Flapping indicates that Event Management can't detect whether the underlying events are genuine. These events could indicate small issues with the way CIs are configured, or larger issues, like network outages.

For example, a server that hosts a web service that has too many active processes might trigger an event about excessive CPU usage. If several events based on the CPU usage are triggered, Event Management
may put
the alert in the flapping state. This depends on the
thresholds set by the administrator.  
Abbildung : 2. Alert flapping diagram

As another example, consider a loose network cable that causes momentary, repeated network
outages.
In this case, if there was no set threshold for this type of alert set by the administrator, then
Event Management
won't considers it as a flapping
alert.
**Zugehörige Konzepte**   

* [Event Management](https://servicenow-prod.fluidtopics.net/ZUCHCl9UolUw_cDu6NWAhw "ServiceNow Event Management is a robust application that helps keep your IT systems healthy by spotting problems quickly and fixing them. It collects events from different sources, figures out what's causing the issues, and converts them into alerts. These alerts are then analyzed, grouped, and acted upon to resolve issues and maintain system health.")
* [Exploring Service Operations Workspace for ITOM](https://servicenow-prod.fluidtopics.net/OgLxW4tgJfDAxIQZafQJSQ "Discover how Service Operations Workspace for ITOM streamlines the entire life cycle of alerts, including alert generation, notification, grouping, analysis, investigation, resolution, and closure.")