Auvik Network Management lets you monitor pings to a public IP address, such as the Internet connection for your network. These are known as cloud ping checks. See How do I start, stop, add, edit, or delete monitoring for services? for information about setting up a cloud ping check.
Auvik automatically detects Internet connections and sets up a cloud ping check. See How do I manage Internet connections? for more information.
Here’s how to create an alert using Alerts v2 to monitor packet loss on a cloud ping check.
Steps to create the alert
- Go to the global, multi-site, or site level where the cloud ping check belongs.
- If the alert is for a single cloud ping check, create it at the site level and select the cloud ping check by name.
- If the alert monitors multiple cloud ping checks, create it at the global site or parent multi-site level. Using a consistent naming convention makes it easier to select the intended checks with a name filter.
- Navigate to Manage Alerts > Alerts v2.
- Click Add Alert.
- Enter the Alert Name.
- Enter the Alert Description.
- Set Apply Conditions to Services.
- Select the cloud ping checks.
- Click + Add Rule.
- Select Service Name.
- For a single check, select equal to and enter the cloud ping check name.
- For multiple checks, use a filter such as contains, starts with, or ends with to select the intended checks.
- Set the Alert Severity.
- Define the Trigger Conditions.
- Add a rule where Cloud Ping Packet Loss is greater than the desired threshold.
- Enter a Trigger Message.
- Type
$to see the list of available variables.
- Type
- Set the Alert Delay.
- Use an alert delay to prevent short-lived packet-loss events from generating notifications. If the condition clears before the delay expires, the alert should not be generated.
- Add Notifications.
- If you add email notification channels, set the desired email delivery delay.
- Define the Clear Conditions.
- Use a custom clear condition.
- Set the clear threshold below the trigger threshold with enough separation to prevent the alert from repeatedly triggering and clearing near the threshold.
- Define the Clear Message.
- Click Complete and Save.
Investigating repeated “Internet Connection Is Lost” alerts
Repeated alerts are not necessarily false positives. If the cloud ping check shows sustained packet loss—especially 100% loss over multiple check intervals—the Internet connection or monitored public endpoint may genuinely be unreachable.
The time required for an alert to trigger depends on the cloud ping check interval, failed-check threshold, alert delay, and alert conditions. For example, a check configured to run every minute and require three consecutive failed checks may take approximately three minutes before the connection is considered down. These settings can be changed, so do not assume that every alert uses the same timing.
Brief outages may clear automatically after the connection recovers, depending on the cloud ping check settings and the alert’s clear condition.
How to confirm whether the alert represents an outage
- Open the affected cloud ping check and review its history.
- Check the packet-loss percentage and round-trip-time graphs for the alert period.
- Confirm whether the loss was isolated to one check or continued across multiple intervals.
- Compare the timestamps with available ISP modem or router logs.
- If the site uses SD-WAN, compare the alert period with path analytics, tunnel events, or provider incidents.
Auvik’s cloud ping checks use ICMP. Confirm that the monitored public endpoint is expected to respond to ICMP and that any required Auvik cloud-ping source addresses are allowed. If the check is monitoring the wrong endpoint or the endpoint blocks ICMP, the alert may not accurately represent Internet availability.
Reducing alert noise without hiding real outages
Use the following approaches when alerts are too sensitive:
- Increase the Alert Delay so brief outages have time to recover before a notification is sent.
- Use a custom clear condition with a buffer below the trigger threshold to reduce repeated trigger-and-clear cycles.
- Review the cloud ping check interval and failed-check thresholds so they match the expected outage-detection time for the site.
- Use stricter settings for critical public endpoints and more forgiving settings for endpoints where brief packet loss is expected.
- Keep the alert enabled while tuning it, and test changes during an approved maintenance window when possible.
Smart Alert Suppression can reduce downstream device-offline alert noise when an upstream device is identified as the cause. It applies only to Alerts v2 and depends on accurate topology information. It does not combine alerts into one message and should not be relied on to suppress the cloud ping packet-loss alert itself. See Smart Alert Suppression for details.
Migrating from the legacy Internet Connection Is Lost alert
Use Alerts v2 for new Internet or WAN loss alerting where the required cloud ping conditions are available.
- Navigate to Manage Alerts > Alerts v2.
- Create or enable the Alerts v2 alert for the intended cloud ping checks.
- Confirm that the cloud ping checks target the correct public IP addresses or public endpoints.
- Verify that the alert is enabled and applied to the expected sites and services.
- Confirm that notifications are being delivered through the expected channels.
- After the Alerts v2 alert has been tested, disable the legacy Internet Connection Is Lost alert if it monitors the same condition.
Legacy alerts and Alerts v2 operate side by side. If both alert definitions monitor the same condition and use the same notification channel, duplicate notifications may be generated.
Test the migration during an approved maintenance window if possible. Confirm that the intended Alerts 2.0 alert fires and clears, and that only one notification path is active. Do not intentionally interrupt a production WAN connection outside of an approved maintenance window.