ICMP Ping Monitoring: When It's the Right Check, and When No Reply Doesn't Mean Down

A few years ago we wrote that ping answers the wrong question for a website: the kernel replies to ICMP even when nginx is dead, so a ping check can stay green through an entire outage. That's still true. It's also only half the story, because there's a lot of infrastructure where ping is exactly the right question: routers, firewalls, VPN endpoints, bare-metal hosts, and anything that has an IP address but no web server.

CompleteStatus now has ping monitors, so this is a good moment to write down how we think about them. When to use ICMP instead of a TCP port check or an HTTP check, why "no reply" is sometimes policy rather than an outage, and why packet loss and round-trip time are more useful than the up/down bit.

What a ping check actually measures

A ping check sends ICMP echo requests to a host and waits for echo replies. Each reply tells you two things:

• The host is reachable. Something at that address, usually the operating system's network stack, received the packet and answered.
• How long the round trip took. The time from request to reply, measured from the probe.

Send a handful of requests and you get a third signal: packet loss, the share of requests that never got a reply.

You can see all three from any terminal:

# Linux / macOS: 5 echo requests, 2-second timeout per reply
ping -c 5 -W 2 203.0.113.10

# Windows
ping -n 5 -w 2000 203.0.113.10

The summary line (5 packets transmitted, 5 received, 0% packet loss and rtt min/avg/max) is essentially what a ping monitor records on every check.

What ping doesn't measure: whether any service on that host works. No port, no protocol, no application. That's both its limitation and its value.

Ping, TCP or HTTP: pick by what the thing does

The rule of thumb is to check the highest layer the target actually speaks.

That fourth row is where ping earns its place even for teams that mostly run websites. If your HTTP check fails and a ping check on the same host is still healthy, the machine and network path are fine and the problem is the web server or the app. If both fail, start looking at the host, the network or the provider. That distinction saves the first ten minutes of an incident. We made a similar case for TCP port monitoring for services that aren't websites.

Why "no reply" doesn't always mean "down"

ICMP is filtered far more often than people expect, and a monitor can't tell the difference between a host that is down and a host that has been told not to answer. Before you trust a ping monitor, check that the target replies to ping at all when it's healthy. Common reasons it won't:

• Cloud security groups. On AWS, a new security group allows no inbound traffic, and that includes ICMP. Unless someone added an ICMP rule, EC2 instances don't answer ping. Other providers' network firewalls behave similarly.
• Host firewalls. Windows Firewall blocks inbound echo requests by default on public networks. Many hardened Linux baselines drop them with iptables/nftables or firewalld.
• CDNs and load balancers. A hostname behind a CDN resolves to the CDN's edge. Pinging it tells you about the edge, not your origin, and some managed load balancers don't answer ICMP at all.
• Upstream filtering. Corporate firewalls and some hosting networks drop ICMP at the perimeter as policy.
• Rate limiting. Routers generate ICMP replies on a slower path than the one that forwards traffic, and many rate-limit or deprioritize them under load. A busy router can drop some pings while forwarding real traffic perfectly well.

If the target doesn't reply when healthy, don't fight it: use a TCP check on a port you know is open. If you control the firewall and want ping monitoring, allow inbound ICMP echo requests (type 8 for IPv4). On IPv6, allow ICMPv6 echo requests too, and don't block ICMPv6 wholesale; neighbour discovery and path MTU discovery depend on it, and blocking it causes the kind of intermittent failures that are miserable to debug.

# nftables: accept echo requests, rate-limited
nft add rule inet filter input icmp type echo-request limit rate 10/second accept
nft add rule inet filter input icmpv6 type echo-request limit rate 10/second accept

Packet loss and RTT: the signals before "down"

Up/down is the least interesting part of a ping check. The trend lines are where the early warnings are.

Packet loss. Zero is normal on a healthy path. Occasional loss of a single packet is usually noise, especially through routers that deprioritize ICMP. Loss that is sustained, or that shows up at the same time every day, points to something real: a saturated link, a failing interface, a congested upstream, a Wi-Fi bridge at a branch office. Loss that climbs over days is the thing to act on before it becomes an outage.

Round-trip time. RTT depends on distance, so the absolute number matters less than changes against the host's own baseline. A server that normally answers in 12 ms and now takes 90 ms has had something change: a routing change at the provider, a congested link, a host too busy to answer promptly. Jitter (RTT that swings widely between checks) is often the first sign of congestion.

Two cautions. Because ICMP replies can be handled on a slow path, a high RTT from a router doesn't always mean traffic through it is slow. And RTT to a host tells you about the network, not about how fast your application responds. For that you want HTTP response times, which we covered in why is my website slow.

How a ping monitor decides the host is down

A single missed check is not an outage. Packets get lost, probes have bad moments, and alerting on every blip is how teams end up ignoring their own alarms.

In CompleteStatus, ping monitors use the same state machine as every other check type:

• A monitor goes DOWN after two consecutive failed checks. The confirming check doesn't wait for the next scheduled interval; it runs about a minute after the first unexpected result, so a 5-minute monitor doesn't take 10 minutes to confirm an outage.
• It comes back UP after two consecutive good checks, confirmed the same way, so a host that is flapping doesn't generate a stream of up/down pairs.
• Repeat outage alerts for the same monitor on the same channel have a 5-minute cooldown.
• Every ping check records packet loss and round-trip time. Round-trip time is charted over time on the monitor page, packet loss is shown for each check, and a sustained slowdown against the monitor's own baseline can raise a response-time anomaly alert.

One honest limitation: checks currently run from a single region, US East. More regions are on the way, but today a network problem between our probe and your host looks the same as your host being unreachable. When a ping monitor alerts, confirm from a second vantage point before you call your provider. mtr is the quickest way to see where the loss starts:

# 100 probes, report mode: loss and latency per hop
mtr -rwc 100 203.0.113.10

Loss that starts at one hop and continues all the way to the destination is real. Loss at an intermediate hop that disappears further along is almost always that router rate-limiting its own ICMP replies, and can be ignored.

Setting one up

A reasonable starting setup for a host you care about:

1. Confirm the host answers ping when healthy (ping -c 5 from outside your network).
2. Add a ping monitor for the host's IP or hostname.
3. Add the service checks on top: HTTP for anything web-facing, TCP for everything else. Ping tells you the host is there; the service checks tell you it's doing its job.
4. Route alerts to the channel your team actually reads.
5. Watch packet loss and RTT for a week to learn what normal looks like before you tune anything.

On the Free plan, checks run every 5 minutes. Pro and higher plans allow faster intervals, down to one minute on Pro; the pricing page has the details, and the uptime monitor docs cover intervals and how confirmation works. The ping monitor docs cover packet count and the loss threshold; for services on specific ports, see the port monitor docs.