How can we help?

Using Alerting 2.0


Auvik has been listening to your feedback and we thank you for your interest in the Beta. We look forward to your continued feedback as we move from the Beta to the general release later this year.

Alerts are a big part of your day to stay on top of changes to your network. Auvik has invested in a new alerting engine to address several fundamental concerns and to provide a more scalable and dynamic solution that can more easily adapt to new types of alerts.

By utilizing more powerful conditional logic and controlling the timing of how long conditions need to be true before triggering an alert, our goal is to facilitate richer alerts, reduce alert noise and simplify the ongoing management of alerts. With the addition of device tags, users can easily re-use groups of devices while creating new alerts.

Important Beta Details

The Beta release is a preview of the upcoming new Auvik alerting functionality. As such, it isn’t quite 100% of what the general release will be like. Check out article for more details of how the new Auvik alerting experience will evolve over time.

We will take measures to ensure 100% compatibility between the Beta and the GA release for any alerts created within the Beta. However, there is a possibility that due to changes based on feedback before the GA, that certain parameters, defaults, and other aspects of an alert definition may change. When GA is released, all alerts created will be compatible moving forward.

Since the existing notification channels will serve both legacy and new Beta alerts, please be advised that if you use the same notification channel for similar alerts between the legacy and Beta alerts, you will receive duplicate notifications. For comparison testing purposes, we recommend setting up additional notification channels that are directed towards your test users, so that your business operations are insulated against potential duplicate notifications.

Scope of the Beta

The new Auvik alerting experience will be rolled out as a side-by-side experience with all of your legacy alerting configuration. We’ll incrementally add new alerting functionality in subsequent releases after the Beta. The beta is a great time to evaluate the new alerting capabilities and re-write any noisy legacy alerts.

Legacy Alerting

You will continue to have access to your existing legacy alert definitions and will also continue to receive your usual alerts and notifications through email, Slack, ConnectWise Manage, or any other integrations you currently have configured. Additionally, the Auvik API will continue to operate as usual.

Alerting Scope

The Beta allows you to create new 2.0 alerts at any level within your account hierarchy. Alerts created at the global site-level can be executed on all organizations and sites. Alerts can be created for a very specific site.


Alerts can be applied to sites in a much more flexible manner than the legacy solution. Choose one, many, or all sites to apply a single alert to, and easily clone alerts to make changes to and apply to other sites.

Alert Trigger Conditions

Not all alert trigger conditions will be available at the start of the Beta, but more will be added between the Beta and General Availability. We’ll continue to add more new types of alerts after the general release as well.

All available Beta alert trigger conditions include:

  • Collectors

    • Approval State

    • Connection State

  • Devices

    • High Utilization

      • CPU Utilization (%)

      • Memory Utilization (%)

      • Device Storage Utilization (%)

    • Status

      • Operational Status (Up/Down/Unreachable)

      • Managed Status (True/False)

    • Version Change

      • Software Version

      • Firmware Version

  • Interfaces

    • Interface Utilization Percentage

    • Packets

      • Total Interface Packet Discards

      • Received Interface Packet Discards

      • Transmitted Interface Packet Discards

      • Total Interface Packet Errors

      • Received Interface Packet Errors

      • Transmitted Interface Packet Errors

      • Percentage of Packets being Broadcasted

      • Total Packets Sent and Received

  • VMware Hypervisor

    • Device Name

    • Interface

    • CPU

    • Disk

    • Fan

    • Temp

    • Memory

    • Power supply

    • VM Name

    • Snapshot age

    • Snapshot size

    • Component State

      • Good

      • Degraded

      • Failed

Pre-Configured Alerts

There are no pre-configured alerts using the new Beta functionality, but the legacy versions remain. Once all of the initial alert trigger conditions are available with new alerting, we’ll add several net-new pre-configured alerts in addition to replacing any valuable legacy pre-configured alerts.

Alerting Noise

The Beta includes several alert noise reduction mechanisms, including alert delays, boolean operators for more refined alerts, and being able to alert on any or all interfaces in a single alert. We are still working on the logic for reducing downstream alerting noise, and this will be available post-Beta.

Legacy vs New Alerting Summary



New Alerting Changes

Scope of Alerts

Define, override, or remove alerts at global site-level, multi-sites, or sites.

Define alerts, easily create variants and assign them to any level of your account hierarchy, including global site, multi-sites, and sites.

Managing & Creating Alerts

Navigate to Manage Alerts > Alerts.

Navigate to Manage Alerts > New Alerts.

Devices and Interfaces

Alerts are executed against individual devices and interfaces which results in the need to specify each interface and receive separate notifications for each.

Interfaces are now included in a device and an alert can specify a condition on any or all interfaces in one device which results in only one notification.

Condition Builder

Alert definition conditions can only be built with an AND boolean operator. This requires users to create two alerts if they wanted to monitor two things but only cared if one of them happened.

Alert definition conditions can now be built with ANDs and ORs, and it’s more intuitive to chain multiple conditions together.

Alert Delay

Alerts are triggered immediately when an alert definition’s condition is true. This results in noisy alerts when conditions flap or quickly self-heal.

The Auto-Pause functionality will completely disable an alert if it triggers so often in a certain amount of time.

Any alert can have an alert delay setting which requires the alert definition’s condition to stay true for a specified amount of time, or for the condition to happen so many times within a specified period, before an alert is triggered and notifications are sent.

This functionality will replace the legacy Auto-Pause functionality to reduce noise without the need to completely disable an alert for a time.

SNMP Poller Alerts

Users can build alerts using custom pollers defined in SNMP Poller Settings.

Custom OID alerts are not supported in the Beta, but this capability will be added post-Beta.

Notification Channels

Navigate to Manage Alerts > Notification Channels. Can continue to use as normal for legacy alerts.

Can leverage any existing or create new notification channels from Manage Alerts > Notification Channels to use with legacy or new Beta alerts.

Maintenance Windows

Navigate to Manage Alerts > Maintenance Windows. Can continue to use as normal for legacy alerts.

Can leverage any existing or create new maintenance windows from Manage Alerts > Maintenance Windows to use with legacy or new Beta alerts.

Managing & Creating Tags


Navigate to Manage Tags to build custom tags of devices you work with often to re-use in any new Beta alerts.

For related information, see:
  1. Permissions
  2. Managing and Creating Tags
  3. Managing Alerts
  4. Creating Alerts
  5. Creating Alert Notifications
Was this article helpful?
2 out of 2 found this helpful
Have more questions? Submit a request