For most production hosts, a solid starting point is a 30–60 second check interval, a timeout of about 2–3x normal round-trip time, an alert after 2–3 consecutive failures, and confirmation from at least two monitoring locations. Set latency warnings at 1.5–2x your measured baseline and critical alerts at 3x, and alert on packet loss above roughly 2% (warning) and 10% (critical). Then tune per host type.
Detection Speed Is a Product of Three Settings
Time to detect an outage is roughly interval multiplied by the consecutive-failure count, plus the timeout. A 30-second interval with three required failures means you hear about a hard outage in about 90 seconds. Halving the interval halves that, but also gives transient blips more chances to fire.
Practical defaults:
- Interval: 30 seconds for critical infrastructure, 60 seconds for standard servers, 2–5 minutes for low-priority or bandwidth-constrained devices.
- Timeout: 2–3x the p95 round-trip time, with a floor of about 1 second.
- Consecutive failures: 2 for critical hosts, 3 for most others. A single lost probe is rarely an incident.
Use a Multi-Location Quorum
A failure seen from one vantage point often reflects a problem near the probe, not the target. Requiring agreement from multiple locations is the most effective false-positive filter available. A common rule is "down when at least 2 of 3 locations fail," or a majority when you run five or more. A single failing region can still raise a lower-severity alert, which flags routing or peering problems.
Set Latency Thresholds Relative to Baseline
Fixed millisecond values rarely fit every host. Measure a baseline over at least one week, using p50 for typical behavior and p95 for normal variance, then alert on deviation:
- Warning: sustained latency at 1.5–2x baseline for several consecutive checks.
- Critical: 3x baseline, or an absolute ceiling that breaks your application, such as 250 ms for an interactive API backend.
Pair both: a relative threshold catches a 5 ms LAN link jumping to 20 ms, while an absolute ceiling protects users even when the baseline drifts upward.
Packet Loss and Jitter
Packet loss is often the earliest sign of a failing link or saturated interface. Evaluate it over a rolling window, such as the last 10–20 probes, rather than per check. Typical starting points are above 2% for a warning and above 10% for critical; on LAN paths, any sustained loss deserves investigation.
Jitter, the variation between consecutive round-trip times, matters most for voice, video, and real-time APIs. Around 30 ms is a common warning level for those workloads. For web or batch traffic, treat jitter as a diagnostic signal rather than an alert trigger.
Starting Thresholds by Host Type
| Host type | Interval | Timeout | Failures | Latency warn / crit | Loss warn / crit |
|---|---|---|---|---|---|
| LAN server | 30s | 1s | 2 | 2x / 3x baseline (e.g. 5 / 10 ms) | >0.5% / >2% |
| Cloud VM, same region | 30s | 1s | 2–3 | 2x / 3x baseline (e.g. 20 / 40 ms) | >1% / >5% |
| Cross-continent | 60s | 3s | 3 | 1.5x / 2x baseline or 300 ms absolute | >2% / >10% |
| Edge / IoT device | 2–5 min | 5s | 3–5 | 2x / 3x baseline | >5% / >15% |
Replace the example numbers with your own baselines within the first few weeks.
Tuning to Reduce False Positives
- Review every alert for two weeks. Classify each as real, transient, or probe-side.
- Raise the failure count before lengthening the interval to filter single-probe drops.
- Add a TCP check alongside ICMP. Some networks rate-limit or deprioritize ICMP; a TCP probe on a known port confirms whether the service is actually reachable.
- Recalculate baselines after infrastructure changes such as region moves or new firewalls.
- Separate warning and critical routing. Send warnings to a Slack or Microsoft Teams channel and route critical states to email, Telegram, or a webhook.
UpScanX ping monitoring runs ICMP, TCP, and UDP checks from 15+ global locations, which makes quorum rules simple, and its AI reports flag gradual latency anomalies. For broader setup guidance, see our ping monitoring best practices.
Key Takeaways
- Detection time is roughly interval times failure count plus timeout; tune all three together.
- Require a multi-location quorum before declaring a host down.
- Alert on latency relative to baseline, backed by an absolute ceiling.
- Use rolling windows for packet loss, and reserve jitter alerts for real-time traffic.
- Revisit thresholds after the first two weeks and after every network change.