How to set Alert Delays with Alerts v2

Alerts which immediately trigger with no delay can cause noise when a condition momentarily flaps or a one-off occurrence self-heals before a user even sees an alert.

In addition to an alert definition’s trigger condition, users can use the Alert Delay setting to introduce certain timing elements which will cause an alert to not trigger until the timing element has been fulfilled.

Time Delay

The Time Delay setting defines how long Auvik waits after the trigger condition has been met before creating an alert and sending a notification.

• Once the trigger condition is met, Auvik starts a timer.
• If the condition returns to normal before the timer expires, the alert is not created, no notification is sent, and the timer resets.
• If the condition persists through the time delay, the alert is created and the notification is sent.

For example, let’s say you have some interfaces you want to monitor for packet discards. Interfaces sometimes have a heavy load and packet discards can spike; but it isn't a problem until a packet discard is greater than 100,000 and stays that way for at least 5 minutes. When creating a packet discard alert with a condition threshold of >= 100,000, simply specify a 5 minute time delay value.

Percentage of Occurrences Delay

The Percentage Occurrence Delay setting specifies how frequently a condition must be true—expressed as a percentage of polls—within a specified time window, before an alert is triggered. This should primarily only be used for ping based alerts that poll at a specific interval. All other alerts will yield inconsistent results.

• The condition must be true for at least X% of polls during the specified time window.
• The condition does not have to be true for consecutive polls.
• Once the occurrence percentage threshold is reached within the time window, the alert is triggered.

A minimum of 2 minutes should be used for the specified time window (minute time period).

For example, let’s say you have some interfaces you want to monitor packet discards. Interfaces sometimes have a heavy load and packet discards can spike; but it isn't a problem until the packet discard on the interface spikes over 100,000 packets at least 75% of the time over 15 minutes. When creating a packet discard alert with a condition threshold of >= 100,000 packets, simply specify 75% of occurrences during a 15 minute period.

Number of  Occurrences Delay

The Number of  Occurrences Delay setting allows you to trigger an alert only after a condition occurs a specified number of times within a defined time window. This option is useful when occasional or infrequent occurrences are expected and normal, but repeated occurrences within a short period indicate a potential issue.

Number of occurrences delay complements the existing percentage-based occurrence delay by enabling alerting based on absolute frequency, rather than the proportion of polls where a condition is met.

• The condition must occur at least X times within the specified time window.
• The occurrences do not need to be consecutive.

How to set an Alert Delay on a specific alert

Use an Alert Delay when you want a trigger condition to remain active for a defined period before Auvik creates the alert and sends a notification. This can help prevent notifications caused by momentary blips or conditions that quickly return to normal.

Steps

1. Go to Manage Alerts.
2. Open the Alerts 2.0 table.
3. Locate and select the alert definition.
4. Click Edit.
5. Find the Alert Delay setting after the trigger condition and trigger message.
6. Enter the required delay.
7. Review the rest of the alert definition and click Save.

If the trigger condition returns to normal before the delay expires, Auvik does not create the alert or send the notification. If the condition remains active for the full delay, Auvik creates the alert and sends the configured notification.

Choose the correct scope

To apply the same delay across sites that inherit the alert, edit the alert from the organization, global, or parent multi-site dashboard.

To apply the delay to only one site, edit the alert from that site’s dashboard. Site-level changes affect that site and may not be replaced by later parent-level edits.

Review inherited and site-specific alert definitions carefully before saving changes.

Additional considerations

• Use a delay that filters expected transient conditions without delaying notification of a genuine outage.
• Confirm that the alert’s trigger and clear conditions still match the intended monitoring behavior.
• If the alert is a legacy alert and does not provide an Alert Delay setting, review the related health-check frequency and minimum-failure settings instead.
• Test the updated alert with a safe condition when possible.

For more information, see How do I manage device health check frequencies? and How do I add, edit, or delete alerts?.

Why didn’t an outage trigger an alert?

If an alert has a trigger delay, the monitored condition must remain true for the entire delay before Auvik creates the alert and sends a notification.

For example, if the Alert Delay is set to five minutes, an outage that lasts only two minutes may recover before the alert is created. This commonly occurs during brief power interruptions, firewall failovers, or high-availability events.

How to change the trigger delay

1. Go to Manage Alerts > Alerts v2.
2. Open the alert definition.
3. Review the Alert Delay setting.
4. If Time Delay is selected, check how long the trigger condition must remain true.
5. Reduce the delay or select No Delay if immediate notification is required.
6. Save the alert.

Use No Delay only when the monitored condition is stable enough that brief interruptions will not create excessive noise. A short delay, such as 15 to 60 seconds, may be a better option when transient interruptions are common.

For more information about creating and editing Alerts v2 definitions, see:

Creating Alerts using Alerts v2
https://support.auvik.com/hc/en-us/articles/27945182903060-Creating-Alerts-using-Alerts-v2

Use different delays for different priorities

You can create separate alert definitions when different devices require different response times.

For example:

• Critical devices: use a short delay or no delay.
• Standard devices: use a longer delay to reduce alerts caused by brief interruptions.

If multiple alert definitions monitor the same devices and condition, review their notification channels carefully to avoid duplicate notifications.

Validate the change

Test the updated alert during a planned maintenance window or with a non-production device whenever possible.

1. Confirm that the alert is enabled and scoped to the intended devices.
2. Verify the configured Alert Delay.
3. Test a controlled outage or state change.
4. Confirm that the alert is created within the expected time.
5. Restore the device or service.
6. Confirm that the alert clears normally.