Alerts FAQ

Alert fatigue—we’ve all been there! The problem with too many alerts is that important problems can be hard to see if you need to look for them in between other notifications that aren’t relevant and actionable to your business. Here are some tips on how to fine-tune your alerts and get the most value out of your Auvik notifications.

One point of caution before you get started on fine tuning alerts—ensure that you always look into whether or not the alert is being caused by a legitimate issue before making changes to the alerts. For example, a High Interface Utilization alert could be caused by a backup saturating a 1 Gbit/s port, or it could be caused by a port connected at 10 Mbit/s when it should be connected at 1 Gbit/s. The action required for each of these situations is much different.

The following tips will involve editing your alert settings, which can be done either at the Organization/multi-site level to apply to all child sites, or at the site level to apply to only that site.

Find additional information at this link: How do I edit alerts?

When editing an alert, you have the option to define its “Email Frequency”. This setting controls how often email notifications from the alert are sent out to users about this particular alert. If the alert triggers multiple times within its email frequency, those alerts will be bundled together into 1 email notification. Note that this option doesn’t affect other notification channels such as webhooks or PSA integrations.

If you find that an alert entity is meeting its trigger condition quite often, you may want to fine-tune these values to something more beneficial to your monitoring.

For example—if an alert is monitoring usage on an interface but you know that particular interface is often quite busy, you can edit the alert and increase the amount of usage required to set off the alert.

If you find that an alert entity is hovering very close to its trigger and clear conditions, you may want to change the alert so the trigger condition and clear condition are not as close together. 

For example—you have a device whose storage is constantly hovering around 80%, and an alert set to trigger at >80% and clear at <80%. You can edit the alert and set the clear condition to a lower number, like 70%, to confirm that the issue is fully addressed before the clear condition is met.

If you have a device or type of device on the network that you don’t want monitored by a certain alert, you can exclude the device or device type from the entity field of that alert.

Find additional information at this link: How do device and interface search and selection work?

If an endpoint is incorrectly classified as an Access Point or Network Element, it may trigger a device offline alert when it disconnects.

To correct the classification:

1. Open the affected device from the Auvik dashboard.
2. Click Edit.
3. Change the device type to the correct endpoint type, such as Tablet or Workstation.
4. Click Save.

After updating the classification, safely test the configuration by simulating an endpoint going offline. Confirm that the endpoint does not generate a critical infrastructure alert.

Find additional information at this link: How do I edit device details?

To prevent incorrectly classified endpoints from generating infrastructure alerts, limit the alert scope to true infrastructure device types.

For legacy alerts, edit the Network Element Offline alert and limit the entity selection to infrastructure types such as switches, firewalls, routers, and access points.

For Alerts v2, create conditions or a tag that targets infrastructure devices and excludes endpoints. For example, include switches, firewalls, routers, and access points while excluding workstations, tablets, and other endpoint types.

Where possible, improve the data used for device classification by confirming that SNMP is enabled on network infrastructure and that the appropriate discovery services and credentials are configured.

Find additional information at these links:

• Alerts v2 - Creating Your First Alerts
• Managing and Creating Tags for Alerts v2
• Why doesn’t my topology map look right?

Not all service providers monitor all devices, so sometimes you may want to disable certain default alerts. For example, if you don’t want to monitor your customer’s printers you can disable any printer related alerts.

Find additional information at this link: How to disable an alert?

By integrating Auvik into your PSA system, you can choose exactly which alerts you’d like to receive tickets/notifications for. You’re also able to build business logic into the alerts from within the PSA, such as separating out alerts for clients on 7x24 monitoring contracts and 5x8 monitoring contracts. Or, if you only want to see Critical alerts, you might choose to only push those alerts through to your PSA.

The link below has some information about setting up various PSA integrations with Auvik:
Third-party integrations with Auvik

If you’re getting frequent device up/down alerts but the devices in question are still online, it’s likely that the device is dropping the ping requests—this can happen if a device is very busy. In this case you can alter your health check settings to increase the number of failed pings required to flag a device as “down” by editing the related health check.

Find additional information at this link: How do I manage device health check frequencies?

If you find that the same alert is triggering quite often—rather than simply silencing it, it’s recommended that you investigate the root cause to see if there are any potential issues that need to be actioned. If you have any questions about a particular alert, please feel free to reach out to Auvik support.

In rare cases, a temporary processing delay may defer alert generation or updates for a subset of events. When this occurs, a device may be down before the alert appears, or test events may not appear immediately and may arrive together after processing resumes.

This is different from an intentional alert delay configured in Alerts v2. Before contacting Support, confirm that the alert definition does not include an alert delay, maintenance window, or suppression rule that explains the timing.

What you may see:

• A device is down, but the related alert appears several minutes later.
• Multiple test events or alert updates arrive together.
• The alert timing differs from the time shown in the device or interface status.

What to do:

1. Check the Auvik system status page for an active incident or degraded service.
2. Confirm the alert definition, trigger delay, maintenance windows, and suppression settings.
3. Verify that the assigned collector is online and healthy in Auvik.
4. If the delay continues, contact Auvik Support with the device, site, alert name, expected alert time, actual alert time, and time zone.

No configuration change is typically required for a temporary processing delay. Once processing returns to normal, alert events and updates should be reflected in Auvik. Alerts will clear according to their configured clear conditions.

For testing notification delivery, see How to Use the Send Test Alert Function.

For more information about service incidents, see Service incidents at Auvik.

If Auvik identifies a device as the wrong type—for example, a firewall instead of an endpoint—or a VoIP phone is included in an infrastructure alert, the device may trigger alerts that do not apply to it.

First, review the device’s current type, management status, and credential status. Auvik uses discovery information from protocols such as SNMP, WMI, and CLI access to help identify devices.

If the device is supported but classified incorrectly:

1. Open the device from the Auvik dashboard.
2. Click Edit.
3. Change the device type to the correct type.
4. Click Save.

If fresh discovery data is required, verify the correct SNMP or CLI credentials and rediscover the device where that option is available.

Deleting a device should not be the first troubleshooting step. Deleting removes the existing device record, historical data, and alert associations. If the device is discovered again, Auvik creates a new device record rather than restoring the previous history.

Where supported, verify that SNMP is enabled, the correct credentials are configured, and LLDP or CDP is enabled when topology information is required.

Find additional information at these links:

• How do I edit device details?
• Why doesn’t my topology map look right?
• Troubleshoot SNMP credentials
• Why an Offline Alert Is No Longer Visible

To prevent incorrectly classified endpoints from generating infrastructure alerts, limit the alert scope to the intended device types.

For legacy alerts, edit the affected alert and exclude incorrect devices or device types from the entity field.

For Alerts v2, use device-type conditions, tags, or device-selection rules to limit the alert to the intended infrastructure devices.

For example:

• Include switches, firewalls, routers, and access points in infrastructure alerts.
• Exclude VoIP phones, workstations, tablets, and other endpoint types.
• Create a separate alert definition for phones or other endpoint categories when they require different monitoring.

If the device remains misidentified after rediscovery and valid credentials have been verified, contact Auvik Support. Include the device make, model, firmware version, device type shown in Auvik, sysObjectID or sysDescr values if available, screenshots of the misclassification, and the alert timestamps.

Find additional information at these links:

• Alerts v2 - Creating Your First Alerts
• Managing and Creating Tags for Alerts v2
• How do device and interface search and selection work?
• Known Issue with third-party SNMP software causing misclassification in Auvik

In rare cases, a temporary processing delay may defer alert generation or updates for a subset of events. When this occurs, a device may be down before the alert appears, or test events may not appear immediately and may arrive together after processing resumes.

This is different from an intentional alert delay configured in Alerts v2. Before contacting Support, confirm that the alert definition does not include an alert delay, maintenance window, or suppression rule that explains the timing.

You may notice that:

• A device is down, but the related alert appears several minutes later.
• Multiple test events or alert updates arrive together.
• The alert timing differs from the device or interface status history.

What to do:

1. Check the Auvik system status page for an active incident or degraded service.
2. Confirm the alert definition, trigger delay, maintenance windows, and suppression settings.
3. Verify that the assigned collector is online and healthy in Auvik.
4. If the delay continues, contact Auvik Support with the device, site, alert name, expected alert time, actual alert time, and time zone.

No configuration change is typically required for a temporary processing delay. Once processing returns to normal, alert events and updates should be reflected in Auvik. Alerts clear according to their configured clear conditions.

For testing notification delivery, see How to Use the Send Test Alert Function.

For more information about service incidents, see Service incidents at Auvik.

Not at this time. Auvik automatically generates the subject line for alert emails and the ticket title sent through supported PSA notification channels. The generated format includes information such as the alert name and affected entity, and the format cannot currently be customized in Auvik.

If you use a custom alert definition, you can rename the alert. Because the alert name is included in the generated notification, a clear and descriptive alert name can help provide additional context.

For Alerts 2.0, you can also customize the trigger and clear messages with supported notification variables. These messages add context to the notification body; they do not change the generated subject-line format.

Find additional information at these links: Alerts v2: Notification Variables and How do I use variables in alert descriptions? 

As a workaround, administrators may be able to use rules in their PSA or mail gateway to rewrite subjects, prepend client or priority text, or route notifications based on message headers or body content. These changes must be configured in the external system and are not controlled by Auvik.

You can also use separate notification channels to route alerts to different email addresses, PSA queues, or teams. Where supported by the PSA integration, use its workflow rules to set priority, category, assignment, or queue based on the alert name, severity, device type, or other available fields.