Auvik Alerts

Auvik alerts are condition-based notifications generated when a monitored entity (device, interface, network, service) crosses a threshold or changes state. This skill covers the severity model, the status lifecycle, and the dismissal semantics that confuse new users.

Anti-triggers

• An alert raised by an endpoint's RMM agent — Auvik alerts come

from SNMP and ICMP polling of network infrastructure, never from software running on a workstation or server; use atera or ncentral.

• A public website or endpoint being down — that is external

uptime checking, not internal polling; use betterstack-monitors.

• Conditions a site collector raised about LAN devices — different

product, different alert engine; use domotz-alerts.

• Who gets paged, and when it escalates — Auvik has no on-call

model; use pagerduty-oncall or rootly-oncall.

Tools

Severity

Severity values, in increasing order:

Default triage filter is severity >= warning - info alerts drown the queue and are rarely actionable.

Status

closed is the only "the problem is fixed" state. dismissed is "a human decided not to look at this" - the underlying condition may or may not still hold.

Dismissal Semantics

Dismissing an alert does not fix the underlying condition.

Auvik's alert engine evaluates conditions on a recurring schedule. If you dismiss an alert and the condition still holds when the engine next evaluates, a new alert (with a new ID) will appear. This is the source of the "we keep dismissing the same alert" pattern in noisy tenants.

Three appropriate uses of dismissal:

1. Known noise - the condition is a confirmed false-positive for this tenant (e.g. link flap on a known-flaky access port on an unmanaged switch).
2. Already-acknowledged - someone has already opened a ticket and is working it; dismissal removes it from the queue.
3. Transient that cleared - the condition cleared between alert fire and triage; dismissing closes the loop.

Two inappropriate uses:

1. Suppressing a real condition - if the device is genuinely down, dismissing buys you 15 minutes of silence before the next alert. Fix the device.
2. Bulk-clearing the queue - if the queue is too noisy, the alert rules need tuning, not dismissal.

Common alertName Patterns

The exact set varies, but in practice these dominate MSP NOC queues:

Entity Resolution

Every alert references an entityId and entityType. To make a good triage decision, you almost always need to pull the entity:

• entityType = device -> auvik_devices_get
• entityType = network -> auvik_networks_get
• entityType = interface -> the parent device via auvik_devices_get

Critical alerts on manageStatus = unmanaged devices are almost always discovery noise, not real incidents.

Workflow

1. auvik_alerts_list status=open (scope by tenant if needed).
2. Order by severity desc, then detectedTime asc.
3. For top-of-queue items, auvik_alerts_get for the full record.
4. Resolve the entity for context.
5. Decide: action, investigate, or dismiss-with-justification.
6. Dismiss only after the user confirms.

Edge Cases

• Some alerts have empty description fields - the alertName plus the entity is the whole signal.
• detectedTime is UTC.
• An alert can reference an entity that has since been deleted in Auvik - the entity fetch will 404. Treat this as evidence the alert is stale and a candidate for dismissal.

Related Skills

• devices
• networks
• api-patterns