Why Devices Can Show Down Even When They’re Up outside Auvik?

A device in Auvik can sometimes appear as Down even though it is powered on and functioning normally. This typically occurs when communication between the Auvik collector and the monitored device is interrupted.

When troubleshooting false Down alerts, begin by verifying connectivity between the collector and the monitored device.

Common reasons a device appears Down

A device may show as Down when:

• ICMP is blocked by a firewall or ACL.
• The device is configured not to respond to ping requests.
• The collector cannot reach the device management IP.
• Routing, NAT, or VLAN changes interrupt connectivity.
• Packet loss causes repeated ping failures.
• WAN, VPN, or site connectivity is intermittent.
• The monitored IP address is no longer assigned to the device.
• The device responds to other protocols but not ICMP.
• Device CPU load, management-session limits, or control-plane protection affects management traffic.
• Multiple devices or interfaces experience the same interruption because they share a network path or upstream device.

These conditions can result in short-lived or recurring bursts of device-down or interface-down alerts, particularly overnight or during periods of intermittent connectivity.

Troubleshooting

Step 1: Test connectivity from the collector network

Verify whether the Auvik collector can successfully reach the device’s monitored IP address.

If the collector cannot reach the device, Auvik may report the device as Down even when the device is operating normally.

For interface alerts, also verify whether the interface is actually down or whether the interface is being affected by a broader connectivity issue.

Step 2: Review firewall and ACL rules

Confirm that required management traffic is allowed between the collector and the monitored device.

Review:

• Local device firewall settings
• Network firewall rules
• ACLs
• VLAN and inter-subnet policies
• VPN policies
• Security policies affecting ICMP, SNMP, SSH, or other monitored protocols
• Any recent firewall, routing, or access-control changes

Step 3: Verify the monitored IP address

Ensure Auvik is monitoring the correct management IP address.

If the device IP has changed or the monitored IP is outdated, Auvik may continue attempting to reach an invalid address.

Use stable management IP addresses where possible and keep device addressing current.

Step 4: Check the collector and network path

Confirm that the assigned Auvik collector is online and able to communicate with the affected devices.

If multiple devices or interfaces alert at the same time, look for a shared cause, such as:

• WAN or VPN instability
• A site connectivity interruption
• An upstream switch, router, or firewall issue
• A shared VLAN or routing problem
• A change to the collector’s network access

Correlate the alert timestamps with WAN-provider events, firewall logs, device logs, or other network events.

Step 5: Review health-check settings

Auvik health checks determine how many consecutive ping failures are required before a device is considered offline.

If a device is prone to brief connectivity interruptions, review the applicable health check and consider increasing the number of failed pings required before the device is marked as offline.

Use caution when changing these values. Increasing the failure threshold can reduce false alerts, but it may also delay notification of a genuine outage.

Find additional information at this link:

How do I manage device health check frequencies?

Step 6: Add an alert delay where appropriate

For Alerts v2, use a sensible trigger duration so that short-lived connectivity blips do not immediately generate an alert.

The delay should be long enough to avoid transient noise while still allowing meaningful outages to be reported promptly.

Find additional information at this link:

Setting Alerts v2 Trigger Conditions

Step 7: Use Smart Alert Suppression for upstream failures

When an upstream device goes offline, downstream devices may also appear offline. Smart Alert Suppression can reduce duplicate alerts by suppressing downstream alerts when Auvik identifies that a parent device is offline.

Before enabling Smart Alert Suppression:

• Confirm that the topology map accurately reflects the network.
• Test the feature in a limited environment where possible.
• Remember that Smart Alert Suppression applies only to Alerts v2.
• Understand that some downstream alerts may occur before suppression takes effect.

Find additional information at this link:

Smart Alert Suppression

Troubleshooting false Access Point Offline alerts

If an Access Point Offline alert occurs while users report no noticeable outage, the AP may have experienced a brief loss of ICMP responses rather than a sustained service failure.

Auvik uses health checks, including ICMP, to determine whether a device is reachable. A short interruption during a radio or channel adjustment, controller handshake, device CPU spike, or similar event can cause a temporary Down/Up transition. The device may appear online again by the time you review the health status, while the alert was still valid for the brief period when ICMP responses were unavailable.

What to check in Auvik

• Review the alert timestamp and confirm whether the AP returned to an online state.
• Compare the alert time with the device’s health-check history.
• Check whether the alert is configured with an Alert Delay.
• Confirm that the alert is scoped to the intended Access Points and is not monitoring devices that should use a different availability policy.

What to check outside Auvik

Review the wireless controller and AP logs around the alert time for:

• Channel changes or radio adjustments.
• AP rejoin or controller-handshake events.
• Firmware checks or controller-driven updates.
• Temporary CPU or control-plane spikes.

Also check the AP’s switch port for:

• Interface errors or discards.
• PoE interruptions or renegotiation.
• Link flaps.
• Cable or transceiver issues.

If multiple APs are affected, review the wireless environment for DFS events, interference, or controller-wide changes.

Reducing noise from brief AP interruptions

For Alerts 2.0, add a small Alert Delay to the AP availability alert. The delay allows the condition to recover before Auvik creates the alert and sends a notification.

Use a delay that is long enough to ignore expected short interruptions but short enough to identify a genuine AP outage. Test the setting against your environment before applying it broadly.

Also confirm that ICMP traffic from the Auvik collector is not being rate-limited or blocked upstream. If controller-based health metrics are available, consider monitoring AP health through the controller in addition to ICMP reachability.

Best practices

To reduce false Down alerts:

• Use stable management IP addresses.
• Keep routing, VLAN, NAT, firewall, and ACL configurations current.
• Confirm that required traffic is permitted between collectors and monitored devices.
• Configure health checks based on the reliability and latency of each site.
• Use alert delays for short-lived conditions.
• Use Smart Alert Suppression for accurately mapped upstream and downstream relationships.
• Investigate recurring alerts instead of disabling them without confirming the cause.

When to contact Auvik Support

Contact Auvik Support if:

• The collector is online but cannot consistently reach multiple devices.
• Alerts continue after network connectivity and health-check settings have been verified.
• The issue requires collector diagnostics, packet captures, or detailed collector resource analysis.
• You need help determining whether a collector, Auvik, or device-side condition is causing the alerts.

When contacting Support, include:

• Affected site and collector
• Device or interface names
• Alert timestamps
• Whether multiple devices alerted at the same time
• Recent network, firewall, routing, or VPN changes
• Relevant device or provider event logs

Summary

Auvik may report a device or interface as Down when communication between the collector and the monitored device is interrupted, even if the device itself remains operational.

Start by checking collector reachability, firewall and ACL rules, routing, monitored IP addresses, and recent network changes. Then review health-check thresholds, alert delays, and Smart Alert Suppression to reduce noise without hiding genuine outages.