Introduction
Alert when ping latency from a device to a specified host climbs above a threshold and stays there. The Network Ping monitor is useful for catching degraded links, saturated circuits, failing VPN tunnels, and flaky upstream connectivity before users start filing tickets.
Like the CPU and Memory monitors, it uses a breach duration requirement so a single slow check doesn't create noise. The alert fires only when average latency stays at or above your threshold for the full configured window.
ℹ️ NOTE: The ping originates from the monitored device, not from Level's infrastructure. You're measuring latency from the device's network position to the target host. The same monitor on two devices in different offices can produce very different results, and that's the point.
How the Network Ping Monitor Works
The Level agent on each covered device pings the host you specify once per minute. Each check sends 5 ICMP echo requests spaced 200 ms apart and measures the average round-trip latency across them. That's a short sample window without generating meaningful traffic.
💡 TIP: Pick a target that actually tells you something, and use separate monitors to cover different layers. A common pattern is three monitors per site: the internal gateway IP (LAN health), an external IP like 1.1.1.1 (internet path, no DNS involved), and an external hostname like google.com. Since the device resolves hostnames through its own DNS, the hostname monitor doubles as a rough DNS health check. If the IP monitor is fine but the hostname monitor errors, DNS is your suspect.
When the average latency meets or exceeds your threshold and stays there for the full breach duration, Level creates an alert. Because checks run once per minute, the breach duration translates directly into consecutive failing checks: a 5 minute breach duration means 5 checks in a row above threshold before the alert opens.
⚠️ WARNING: If zero packets come back, the check returns an error ("Could not ping target: no ping response from...") instead of a latency measurement. This is a separate state from a high-latency alert. A firewall or host that drops ICMP echo will look unreachable even when the service on it is up, so confirm your target responds to ping before relying on this monitor.
The monitor works on Windows, macOS, and Linux. The agent runs elevated, so no extra permissions are needed for ICMP on any platform.
ℹ️ NOTE: The consecutive-check counter only advances on back-to-back failing checks. Any healthy check, or an errored one, resets it to zero. Latency has to stay above the threshold for the entire breach duration without interruption before the alert opens.
Offline Devices and Missed Checks
The agent reports its current monitor state, it doesn't replay history. That has two practical consequences:
Device powered off or agent stopped: No checks run while the device is dark, and nothing is backfilled when it returns. You won't get retroactive alerts for the offline window. Use the Connection monitor to catch the device itself going dark; the ping monitor tells you nothing while the device is offline.
Device up, but its network is down: Checks still run locally and return errors, but the agent can't reach Level to report them. When connectivity returns, the agent reports its current state. If the problem is still ongoing, the alert opens then. If it self-resolved during the outage, nothing is reported, since the blip is already gone.
ℹ️ NOTE: After a device comes back online, a latency alert needs the full breach duration of fresh, consecutive over-threshold checks before it fires. It won't open off a single reading.
Configuring Network Ping Monitor
Open the target monitor policy, then click + Add new monitor. The configuration panel opens.
Name and Type
Enter a name in the Name field. The field is optional, but something like "Branch Office - Gateway Latency" beats an unnamed monitor when you're scanning an alert list.
Set Type to Network ping.
Severity
Set Severity to match how urgent sustained latency to this host is:
Information
Warning
Critical
Emergency
💡 TIP: Latency to a public host like 8.8.8.8 is often outside your control, so Information or Warning keeps the noise down. Latency to your own gateway or a critical internal server is more actionable and may warrant Critical.
Host
Host is the target the agent pings. Enter an IP address (8.8.8.8) or a hostname (example.com), internal or public. The only requirement is that the device can reach it via ICMP. This field is required.
ℹ️ NOTE: If you enter a hostname, the device resolves it through its own DNS. A DNS problem on the device can affect the check even when the network path itself is fine.
ℹ️ NOTE: IPv6 targets work too. The agent picks ICMPv4 or ICMPv6 based on what the target resolves to, as long as the device has working IPv6 routing. A dual-stack hostname resolves to whichever address family DNS returns first, so use an IPv6 literal (like 2606:4700:4700::1111) if you specifically want to test the v6 path.
Threshold
Threshold sets the average latency, in milliseconds, that triggers the monitor. The check breaches when the average round-trip time across its 5 pings meets or exceeds this value. Enter a value directly or use the up/down arrows. Minimum is 1 ms with no upper limit.
💡 TIP: Baseline first, then set the threshold. Latency that's normal for a satellite or LTE-backed site would be alarming on fiber. A threshold of 2 to 3 times the site's normal latency is a reasonable starting point.
Breach Duration
Breach duration sets how long latency must stay above the threshold before an alert is created. Adjust using the slider or the up/down arrows. Range is 0 to 120 minutes.
ℹ️ NOTE: A breach duration of 0 creates the alert as soon as a single check exceeds the threshold. Since checks run every minute, each minute of breach duration adds one consecutive check that must fail. A few minutes here filters out one-off blips like a backup kicking off or a brief routing hiccup.
Remediation
Attach an automation to run when this alert fires. Restart a VPN service, cycle a network adapter, or log diagnostics while the problem is live.
Click in the Remediation field and select an automation.
Use the link icon next to the field to open the selected automation in a new tab.
Click the × to clear the selection.
💡 TIP: Network latency alerts are a good fit for diagnostic remediations. An automation that captures a traceroute and writes it to the alert payload gives you the network state at the moment things went bad, not 20 minutes later when you start looking.
Notifications
Under Notify recipients, choose when the policy's recipients get emailed:
On alert creation — recipients get an email when the alert fires
On alert resolution — recipients get an email when the alert resolves
Recipients are managed at the monitor policy level, in the Recipients section.
Auto-Resolve
Auto-resolve alert when conditions clear closes the alert automatically once latency drops back below the threshold. Leave this on unless you want latency alerts to persist for manual review.
FAQ
How often does the ping check run? Every 60 seconds. Each check sends 5 pings spaced 200 ms apart. These values are fixed and aren't configurable in the UI today.
The target is up but the monitor says it can't ping it. What's going on? Something between the device and the target is dropping ICMP echo, usually a firewall on the target or in the path. The monitor reports "Could not ping target: no ping response from..." when zero packets come back, even if the service on that host is running fine. Allow ICMP from the device's network, or pick a target that responds to ping.
A device was offline overnight. Will I get alerts for latency problems during that window? No. The agent reports its current state when it reconnects, it doesn't replay what it missed. If the problem is still happening when the device comes back, you'll get the alert then. For catching the device itself going dark, use the Connection monitor.
Can I ping an IPv6 address? Yes. Enter an IPv6 literal or a hostname that resolves to IPv6. The device needs working IPv6 routing to the target for the check to succeed.
Can I monitor multiple hosts with one monitor? No, each Network Ping monitor targets a single host. Add a separate monitor to the policy for each host you want to watch.
What's the difference between this and the Connection monitor? The Connection monitor watches whether the device itself is reachable by Level. The Network Ping monitor watches latency from the device to a host you choose. A device can be perfectly online in Level while its path to your file server is falling apart.
The host is internal and not pingable from the internet. Will this still work? Yes. The ping comes from the agent on the device, so anything the device can reach on its own network is fair game.
My alert keeps firing on devices at one site but nowhere else. That's probably the signal working as intended. The same threshold means different things on different links. Create a site-specific tag and a separate policy with a higher threshold for that site rather than raising it globally.
Who can create and edit Network Ping monitors? Technicians with permission to edit monitor policies. Permission settings are managed in Workspace → Permissions.
What happens to open ping alerts if I delete the monitor? Existing alerts remain in place. Deleting a monitor doesn't close alerts it already created, so resolve those manually.