A device may appear offline in Auvik even though it remains accessible from another location. Short, transient offline alerts usually indicate a temporary polling or reachability problem rather than a confirmed device outage.
Auvik evaluates device availability from the monitored IP address and the Auvik collector’s network path. If communication between the collector and device is interrupted, Auvik may mark the device offline even though it is reachable from a workstation, controller portal, or another monitoring system.
Common causes
False or short-lived offline alerts may be caused by:
- Brief packet loss, latency, WAN jitter, wireless interference, or congestion.
- ICMP being filtered, rate-limited, or deprioritized.
- Device CPU spikes or control-plane policing dropping management traffic.
- Temporary SNMP credential, timeout, or access problems.
- Routing changes, STP reconvergence, or interface flaps.
- MTU or fragmentation problems.
- Collector CPU, memory, disk, or network-resource pressure.
- Duplicate IP addresses or an incorrect monitored IP address.
Test reachability from the collector
Test the device from the collector’s network path rather than relying only on a ping from your workstation.
If you have access to the collector host or its diagnostic shell, run a short controlled test.
For a Windows collector:
ping -n 20 <device_ip>
tracert <device_ip>For a Linux-based collector:
ping -c 20 <device_ip>
traceroute <device_ip>If the device responds from your workstation but not from the collector, compare the two network paths. Differences in VLANs, routing, firewall rules, ACLs, NAT, or security policies may affect only the collector.
For information about accessing the collector diagnostic shell, see Diagnose issues using discovery scanning with the Auvik collector?
Verify the monitored IP address
Open the device details in Auvik and confirm that the monitored or primary IP address is the device’s current management IP.
Check for:
- A recent DHCP address change.
- An outdated IP address in Auvik.
- Duplicate IP addresses.
- A management interface that is no longer active.
- A device replacement or network migration.
If the monitored IP is incorrect, correct the underlying addressing issue and update the device information in Auvik as appropriate.
Review the network path
Ask your network administrator to confirm that:
- The collector can reach the device’s management VLAN or subnet.
- ICMP Echo traffic is permitted between the collector and device.
- Routing and return routing are correct.
- NAT is not changing the source address in a way that causes the device to ignore the collector.
- No firewall or ACL rule is intermittently blocking the collector.
- No ICMP rate limit or control-plane policy is dropping health-check traffic.
- The device’s MTU and path MTU are appropriate.
A device that is reachable from a workstation but not from the collector can correctly appear offline in Auvik because Auvik evaluates reachability from the collector’s path.
Check device health and management traffic
Review the device during the time of the alert.
Check for:
- CPU or memory spikes.
- Interface errors or link flaps.
- Control-plane policing or management-traffic rate limits.
- Routing or STP changes.
- Device logs showing dropped or rate-limited ICMP or SNMP traffic.
- Recent credential, ACL, or management-interface changes.
If SNMP, SSH, or another management protocol continues to work while ICMP is intermittent, do not assume the alert is false immediately. Confirm which health check and alert condition generated the event, then compare the alert timestamp with the device and collector logs.
Check SNMP access
If the device is monitored using SNMP, confirm that:
- The correct SNMP credential is assigned.
- The device accepts requests from the collector’s IP address.
- ACLs allow SNMP traffic from the collector.
- The device is listening on the configured SNMP port.
- No recent credential or security-policy change interrupted polling.
For additional information, see Troubleshoot SNMP credentials
Check the collector
Review the collector during the time of the alert.
Check for:
- Collector disconnection or reconnection events.
- CPU, memory, disk, or network-resource pressure.
- Host or virtual-machine pauses and restarts.
- Hypervisor maintenance or migration events.
- DNS or outbound connectivity failures.
If the collector host is resource-constrained, address the host or virtual-machine issue before changing device alert thresholds.
See:
Tune the alert only after checking reachability
If the device is reachable but experiences brief, expected interruptions, review the applicable alert or health-check settings.
Depending on the alerting workflow, you may be able to:
- Increase the number of failures required before the device is considered offline.
- Increase the Alerts v2 trigger delay.
- Apply the change only to the affected devices or sites.
- Use a maintenance window during planned network changes.
Auvik health checks use consecutive failures when determining whether a device is offline. A short interruption may not produce an alert if the device recovers before the configured failure threshold is reached.
For Alerts v2, see How to set Alert Delays with Alerts v2
Devices that intentionally block ICMP
Some devices intentionally block or rate-limit ICMP. If ICMP cannot be enabled safely:
- Ask the network administrator whether ICMP can be allowed from the collector’s IP address only.
- Exclude the device from the applicable offline alert, if appropriate.
- Monitor the device through a supported controller or management system instead.
- Document the exception so the device is not repeatedly treated as an unexpected outage.
Do not exclude a device from offline monitoring unless its alternative monitoring method is reliable and the operational impact is understood.
Evidence to collect if the issue continues
Collect the following information:
- Device name and monitored IP address.
- Collector assigned to monitor the device.
- Alert name and alert timestamp, including timezone.
- Ping and traceroute results from the collector’s network path.
- Device CPU, memory, and interface statistics.
- Relevant firewall, ACL, routing, SNMP, or device-log information.
- Any recent IP, VLAN, routing, NAT, credential, or firewall changes.
- Collector status and resource information during the alert.
If the issue persists after reachability and network-path checks, provide this information to Auvik Support.