Ping Monitoring: What ICMP Checks Prove and Miss

Ping monitoring sends an ICMP echo request to a host on a schedule and records whether a reply comes back, and how long it took. It answers one narrow question: is this address reachable across the network right now. It says nothing about whether the software on that address is doing its job.

What is ping monitoring?

The practice is the repeated use of the ICMP echo mechanism as an availability signal. A probe sends an echo request, the target's network stack answers with an echo reply, and the probe records the round-trip time or the absence of an answer. Repeat every minute and you have a reachability history for a router, a firewall, a virtual machine or a printer.

The mechanism predates almost everything else in this field. RFC 792 defined echo request and echo reply in 1981, and RFC 1122 later made answering them a requirement for internet hosts. That is why it works against devices with no web interface, no agent and no API.

How an ICMP echo request actually works

The probe builds an ICMP type 8 packet carrying an identifier, a sequence number and a small payload. It sends that to the target address. A healthy host replies with a type 0 packet carrying the same identifier and payload. The probe matches the reply to the request by sequence number and subtracts the send time.

Three things can happen instead. The reply arrives late, which shows up as high round-trip time. No reply arrives before the timeout, which counts as a lost packet. Or an intermediate router returns a different ICMP message, such as destination unreachable or time exceeded. Those name the point where the path broke, which is more useful than a bare failure.

One detail surprises people. Routers handle ICMP in their control plane, not their fast forwarding path, and they routinely deprioritise or rate-limit it under load. A congested router can therefore drop echo requests while forwarding ordinary traffic perfectly well.

What a ping check cannot tell you

Reachability is not service health. A server answers echo requests from its kernel, so a machine with a crashed web server, a full disk and an expired certificate still replies instantly. Every ICMP monitoring setup has this blind spot by design, because the protocol carries no concept of a port or an application.

The gap widens with modern infrastructure. An address that answers may belong to a load balancer with no healthy backends behind it, or to an anycast edge that is nowhere near the machine running your code. ICMP monitoring of such an address measures the edge, not your service, and the two can diverge for hours.

The reverse failure is just as common. Plenty of hosts never answer at all. Cloud security groups block ICMP by default, and AWS documents the separate rule type you need to permit it. Many managed load balancers and CDN edges drop it too. A silent host is not automatically a broken one.

Check type	Proves	Misses	Good for
ICMP ping	The address is reachable	Ports, TLS, application state	Routers, switches, appliances, VPN gateways
TCP port	A service accepted a connection	Whether it returns correct data	Databases, brokers, SSH, mail
HTTP or API	A real request got a valid answer	Nothing below its own timeout	Websites and APIs

We prefer ping monitoring for network gear and a TCP or HTTP check for anything with a port number. A ping monitor on a web server tells you the box is up while customers see a 502.

Setting up a ping monitor

A ping monitor needs only a hostname or address and an interval:

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "branch office gateway",
    "type": "ping",
    "target": "gw.branch.example.com",
    "intervalSec": 60
  }'

Run it from more than one place. Six probe regions are available as of September 2026, spanning Los Angeles, Sao Paulo, Bangalore, London, Singapore and Sydney. A path that fails from one continent and succeeds from three others is a routing problem, not an outage, and the difference decides whether anyone should be woken up.

That is the argument behind cross-region quorum: require two regions to agree before a monitor moves to DOWN. Probe source addresses, which you will need if the target sits behind a firewall that filters by source, are published on the probe IP page. Every field accepted by the endpoint is listed in the API reference.

Reading packet loss, jitter and a normal round trip

Packet loss is the share of echo requests that got no reply inside the timeout. Jitter is the variation between consecutive round-trip times. Both matter more than the raw average, because a link that averages 40 milliseconds with 8 percent loss feels far worse than one that averages 90 milliseconds cleanly.

Rough expectations for a wired connection help when you read a graph:

Path	Typical round trip
Same metro	1 to 10 ms
Same continent	10 to 40 ms
Transatlantic	70 to 90 ms
Antipodal	250 to 320 ms
Geostationary satellite	500 ms and up

Light in fibre covers roughly 200 kilometres per millisecond, so those floors are physics rather than product quality. A transatlantic round trip under 60 milliseconds is not a better provider, it is a measurement error or a CDN answering closer to you than you assumed.

Alert on sustained change rather than on one bad sample. A single lost packet is noise on any real network. Loss above a few percent across several consecutive checks is a signal, and rising jitter usually arrives before loss does.

Jitter deserves its own threshold when voice or video crosses the link. A codec buffers a few tens of milliseconds of variation and then gives up. So 30 milliseconds of jitter on a clean 20 millisecond path breaks calls that a loss graph would call healthy. Track the spread, not just the mean.

Packet loss needs the same care in the other direction. Rate-limited ICMP produces a steady one or two percent that never changes and never matters. What matters is the shape: a flat line that suddenly steps up, or loss that climbs with the working day.

Keep a baseline before you set any threshold. Round-trip time to the same host varies by time of day, by route changes at your transit provider and by the season of your own traffic. A number that looks alarming in isolation is often just Tuesday afternoon.

Where ping monitoring goes wrong

Watching from one desktop. The free Windows utilities that dominate this category run on one machine on one network. When that machine's uplink degrades, every host on the dashboard turns red at once. The tool cannot distinguish its own link from a hundred remote failures.

Treating a blocked host as a down host. Confirm with a manual ping before you build a monitor on it. If the target never answers, a TCP check against a port it does serve is the better signal.

Using ICMP as a proxy for service health. It is the cheapest check available and the least specific. Pair it with a check at the layer your users actually touch, which is the point blackbox monitoring makes about probing from the outside.

Setting the interval too tight. Sub-minute ICMP against gear that rate-limits it produces false loss. Start at 60 seconds, watch for a week, then tighten only if the numbers are clean.

Used for what it is good at, ping monitoring is the cheapest reliability signal you can run. It needs no agent, no credentials and no cooperation from the target beyond a stack that answers echo requests. Put it on the network devices between your users and your service, keep application checks for the application, and confirm from a second region before paging anyone. Ten ping monitors on a one-minute schedule cost nothing on the free plan as of September 2026.