The Alert Insights report helps you identify alert noise and target it at the source: the trigger conditions that cause the noise. Instead of reviewing alerts one by one in real time, the report analyzes your own alert history and highlights where noise is concentrated, which devices trigger the most, and where an Alerts v2 delay may reduce unnecessary notifications.
You can find the report under Manage Alerts > Alert Insights Report.
What is Alert Insights?
The Alert Insights Report is a centralized view of alert activity for the last 30 days and is generated once a day. It is designed to help organizations:
Understand alert median resolution per severity
Identify the noisiest devices and alerts
Review AI-generated observations about alert patterns
Suggestions for Alert v2 alert delays that will suppress 50% or 80% of repeated alert noise.
The overall goal is to help reduce alert noise at the source by improving how alerts are configured, especially when moving from legacy alert behavior to Alerts v2.
How the feature works
The Alert Insights report is generated once per day. It uses your organization’s alert data from the last 30 days and presents it in several widgets.
Insights by Aurora
This widget summarizes notable alert trends using Aurora AI.
Examples of insights may include:
a change in critical alert volume compared with the previous period
alerts that appear unusually noisy
devices or tenants that may need attention
anomalies or patterns worth investigating
Aurora-generated insights are intended to help you focus your review. As with any AI-generated summary, you should verify the findings before taking action.
30-day overview
This widget summarizes alert activity by severity over the most recent 30-day period and compares it with the previous 30 days.
For each severity, it shows:
30 Day Count — the total number of alerts triggered in the last 30 days
Changes - compared to the previous 30 days
Open Count — how many alerts of that severity are still open
Median Resolution — the median time to resolution
Noisiest Alert — the alert definition generating the most activity for that severity
Flagged devices
This widget highlights devices that are generating the most alert activity in the past 24 hours. The table is ranked by the duration that a device was in a triggered state. For example, a device with an unresolved outage for 24 hours will be ranked above another device that had 5 separate offline events of 30 minutes each. This table is intended to surface devices that may need quick investigation.
For each flagged device, the table shows:
Device Name
Tenant
Alert Name
Triggered — how many times that alert triggered in the last 30 days
Severity
Opened — the most recent opened alert date
These devices are often the best place to start when looking for flapping behavior, recurring instability, or conditions that may benefit from better thresholds or delays.
Delay suggestions
This widget helps you estimate the value of using Alerts v2 delay settings. For each noisy alert, the table shows:
Alert Name
30 Day Count
Unique Devices
Delay to Suppress 50% - If this value is used, based on data from the past 30 days, 50% of the alerts would have been suppressed.
Delay to Suppress 80% - If this value is used, based on data from the past 30 days, 80% of the alerts would have been suppressed.
In legacy alerting, an alert typically triggers as soon as the condition is met. In Alerts v2, an Alert Delay can require the condition to remain true for a defined period before an alert is created.
For example, if the report suggests a delay of 12 minutes to suppress 50% of alert noise, that means a condition would need to remain true for 12 full minutes before the alert is created. Based on the prior 30 days of the organization's own data, that delay would have prevented about half of the repeated alerts for that alert pattern.
These values are suggestions, not automatic changes. You should review the operational impact before updating any production alert.
How to use it
Review the report at the global site
Start at the top global site, since this is where the report is currently available and where many organizations will want to standardize Alerts v2 definitions.
Read the Aurora summary first
Use the Aurora insights to quickly identify:
unusual spikes or drops in severity counts
noisy alerts worth tuning
devices or tenants that may require investigation
Then validate those observations using the other widgets.
Use the 30-day overview to prioritize severity
Check which severities are driving the most volume and whether the trend is improving or getting worse compared with the prior 30 days.
Investigate flagged devices
Review the devices with the highest trigger volume. Focus on:
Devices that appear to flap
Repeated triggers from the same alert condition
Alerts that stay open or recur frequently
This can help you separate true infrastructure problems from alert configuration noise.
Evaluate delay suggestions before changing alerts
Use the delay suggestions table to estimate how much noise could be reduced by moving an alert to Alerts v2 and applying a delay.
Today, this is a manual process. To act on a suggestion, you must find the alert and update or recreate it in Alerts v2.
For steps on creating Alerts v2 alerts, see Creating Alerts using Alerts v2.
Best practices
Start with the noisiest alerts.
Review suggested delays in the context of operational risk. A longer delay reduces noise, but it may also slow detection for conditions you care about.
Standardize Alerts v2 alerts at the top level where possible, then apply them to child sites as needed.
Use the 50% suppression value as a conservative starting point when you are unsure.
Investigate the underlying cause of noisy alerts before relying only on suppression. In many cases, the right fix is improving the trigger condition or resolving a flapping device.
Avoid duplicating legacy alerts and Alerts v2 alerts for the same condition and notification path, since that can create duplicate notifications. Consider running in parallel in Auvik for comparison, first.