Auvik supports alerting on custom SNMP Poller values, but SNMP Poller alerts and device tags do not currently share the same scoping model in every alerting workflow.
Device tags are an Alerts v2 feature. SNMP Poller alert definitions may be managed through the legacy alerting workflow. As a result, a device tag cannot be used to dynamically scope an SNMP Poller alert when that alert is running in the legacy engine.
The practical consequence is that administrators must explicitly select the devices that should receive a poller alert, or maintain separate alert definitions for different device groups.
Current behavior
Device tags are associated with Alerts v2
In Alerts v2, tags represent reusable, dynamic groups of devices. A tag can be selected while creating or editing an alert definition, and the devices represented by that tag are used when the alert executes.
Tags are useful when device membership changes over time—for example, when a naming rule, device class, site, or other property identifies a consistent group of devices.
SNMP Poller alerts use poller-specific conditions
SNMP Poller alert conditions are built from the name of the SNMP Poller setting. For example, a poller named Environmental probe creates a variable such as $environmentalProbe. Special characters are removed from the generated variable name.
Because the poller metric is created from the custom SNMP Poller setting, the alert must first have an SNMP Poller setting and associated device data. Auvik’s alert workflow instructs administrators to search for the poller name when selecting the metric.
Why tags cannot be used for this scope today
When the SNMP Poller alert is handled by the legacy alerting engine, the alert does not consume the dynamic device-tag selection used by Alerts v2. The alert must instead be scoped using the device-selection options available in the legacy workflow.
This is a product behavior, not an indication that the tag is malformed or that the tag rules are failing.
Workaround 1: Explicitly select devices at the site level
Use an explicit device list when the poller alert must apply to a known group of devices.
- Confirm that the SNMP Poller setting exists and is assigned to the intended devices.
- Go to Manage Alerts.
- Create or edit the alert for the required SNMP Poller metric.
- Configure the trigger condition and clear condition.
- At the site level, explicitly select each device that should receive the alert.
- Save the alert and verify that the selected devices are included.
This approach is the most predictable workaround because the alert scope is stored directly on the alert definition rather than inferred from a tag.
Use it when:
- The target device list is small or changes infrequently.
- The same poller has different thresholds for different device groups.
- A device tag exists but cannot be selected by the poller alert workflow.
- You need a site-specific exception.
Workaround 2: Clone the alert for different device sets
Create separate alert definitions when different device groups need different thresholds, severities, delays, or recipients.
For example:
SNMP - UPS Battery - Core NetworkSNMP - UPS Battery - Branch OfficesSNMP - Environmental Probe - Server Rooms
For each copy:
- Clone or duplicate the existing alert definition when that action is available.
- Give the copy a descriptive name that identifies the site or device group.
- Change the explicitly selected devices.
- Adjust the trigger, clear condition, delay, severity, or notification channels as required.
- Save and test the copy independently.
Alerts v2 supports cloning to create variants for specific sites. If the SNMP Poller alert is a legacy alert, use the equivalent legacy copy or site-specific alert workflow available in your Auvik environment.
Workaround 3: Move equivalent logic to Alerts v2 when possible
If an equivalent built-in or custom Alerts v2 trigger exists, consider recreating the alert in Alerts v2. This can provide access to:
- Device tags
- More flexible site and organization scope
- Reusable alert variants
- AND/OR condition logic
- Alert delays that reduce noise from short-lived conditions
- A clearer device-selection count during configuration
Do not migrate solely because the alert is inconvenient to scope. First confirm that Alerts v2 supports the same metric and semantics. If it does not, keep the SNMP Poller alert in the legacy workflow and use explicit device selection.
Also check for duplicate notifications before enabling an equivalent v2 alert. If both a legacy alert and an Alerts v2 alert use the same condition and notification channel, Auvik may send notifications from both definitions.
Recommended configuration procedure
1. Identify the poller and its assigned devices
Use the SNMP Poller views to confirm which devices have the poller and what values Auvik is receiving:
- At the site level, go to Debug > All SNMP Pollers to view devices, poller names, current values, and historical data.
- From a device dashboard, open Debug > SNMP Poller to inspect pollers assigned to that device.
- If you use automation or reporting, the SNMP Poller API can return the devices associated with a specific poller setting.
Do this before editing the alert. It prevents an alert-scope problem from being confused with a polling or data-collection problem.
2. Confirm the alert source
Auvik displays whether an alert came from a Legacy or V2 alert definition in the alert details. Use that field when the alert’s behavior is unclear.
For easier administration, use a naming convention such as:
LEGACY - SNMP - UPS BatteryV2 - High Storage - Servers
3. Configure the poller-specific condition
Select the SNMP Poller metric by searching for the poller setting name. Review the generated variable and confirm that the trigger and clear conditions match the poller’s data type and intended behavior.
Every alert should have an alert name, description, severity, trigger condition, and clear condition. Add an alert delay or repetition control when short polling fluctuations could create unnecessary notifications.
4. Select the devices explicitly
For a legacy SNMP Poller alert, select the target devices directly at the site level. Record the device names, site, poller name, threshold, and notification channel in the alert description or operational documentation.
5. Test and document the result
Validate the alert using a safe test condition or a non-production device when possible. Confirm that:
- The poller value is current.
- The intended device is included in the alert definition.
- The trigger condition is evaluated.
- The notification reaches the correct destination.
- The clear condition resolves the alert as expected.
Operational guidance
Use consistent device naming and site organization
Explicit selection becomes easier to maintain when device names and site placement are consistent. Include an operational role or location in names where appropriate, such as:
CHI-CORE-SW01EDM-BRANCH-UPS01TOR-SERVERROOM-ENV01
Naming does not replace explicit alert selection, but it makes reviewing and rebuilding the device list faster.
Keep a scope register
For each SNMP Poller alert, document:
| Field | Example |
|---|---|
| Alert name | LEGACY - SNMP - UPS Battery |
| Poller setting | UPS battery percentage |
| Scope | Edmonton site; UPS01, UPS02 |
| Trigger | Below 25% for 10 minutes |
| Clear condition | Above 30% |
| Notification | NOC email and PSA |
| Owner | Network Operations |
| Review date | Quarterly |
Review this register after adding devices, moving devices between sites, changing poller settings, or changing alert ownership.
Be careful when editing inherited alerts
An alert created at an MSP or parent level may affect multiple client or child sites. Confirm the alert’s creation site and inheritance before changing its device list. If only one site needs a different scope, create a site-specific variant or clone rather than changing a shared definition unintentionally.
Monitor poller lifecycle changes
Deleting an SNMP Poller setting automatically disables associated alerts. If the poller is later restored or recreated, review the disabled alert, redefine its trigger conditions if needed, and re-enable it.
Troubleshooting
The tag contains the device, but the alert does not trigger
Check the alert source. If the alert is Legacy, the tag is not being used to scope it. Add the device explicitly or recreate equivalent logic in Alerts v2 if the required metric is supported there.
The device is selected, but no value is available
Open Debug > All SNMP Pollers at the site level and confirm that the device has a current value for the poller. If no value is present, investigate the SNMP credentials, connectivity, poller assignment, OID or data type, and collector reachability before changing the alert scope.
The alert was duplicated during migration
Check the alert source and notification channels. Disable or remove the redundant definition only after confirming which alert should remain active. Alerts without notification channels can still appear in Auvik’s Alerts dashboard, so removing notifications is different from disabling the alert.
The alert stopped after a poller change
Review whether the SNMP Poller setting was renamed, deleted, reset, or recreated. Because the alert condition is based on the poller setting name, a renamed or replaced poller may require the alert condition to be reviewed.
Summary
Device tags are a powerful way to manage reusable device scope in Alerts v2, but they cannot currently be relied on to scope SNMP Poller alerts that run through the legacy alerting engine. For those alerts, explicitly select devices at the site level, clone definitions for different device sets, and document the intended scope.
When equivalent alert logic becomes available in Alerts v2, evaluate migration to gain tag-based scope and more flexible alert variants. Until then, consistent naming, organized sites, current poller verification, and a maintained scope register provide the most reliable operational workaround.