ICMP (Ping) Monitoring - When and Why to Use It
HTTP checks tell you if your application responds. Ping monitoring tells you if the machine is even reachable. Here's when ICMP monitoring matters and how to use it effectively.
Not Everything Speaks HTTP
Most uptime monitoring focuses on HTTP - send a request, check for a 200 response, measure the response time. That works perfectly for websites, APIs, and web applications. But not everything in your infrastructure runs a web server.
ICMP (Internet Control Message Protocol) monitoring - commonly called "ping monitoring" - operates at the network layer. It checks whether a host is reachable and responsive at the most fundamental level, without caring what services are running on it.
If HTTP monitoring asks "is your application working?", ICMP monitoring asks "is your machine even turned on and connected to the network?"
How ICMP Monitoring Works
ICMP monitoring sends an Echo Request packet to a target host and waits for an Echo Reply. This is the same mechanism behind the ping command you've probably used hundreds of times in a terminal.
The check measures three things:
| Metric | What it tells you |
|---|---|
| Reachability | Can network packets reach the host at all? |
| Round-trip time (RTT) | How long does a packet take to travel to the host and back? |
| Packet loss | What percentage of packets are being dropped? |
No application code is involved. No web server needs to be running. No ports need to be open. ICMP operates below all of that - it's a conversation between network stacks, not applications.
When to Use ICMP Monitoring
Network Infrastructure
Routers, switches, firewalls, and load balancers often don't serve HTTP traffic directly. ICMP is the standard way to verify these devices are online and responsive.
- Core routers - Is your backbone connectivity intact?
- Firewalls - Is the device processing traffic?
- Load balancers - Is the balancer itself reachable (separate from the services behind it)?
- VPN gateways - Is the tunnel endpoint responding?
Bare Metal and Virtual Servers
Before checking whether your application is running, you might want to know whether the underlying server is reachable. This is especially useful for:
- Dedicated servers in colocation facilities where you manage the hardware
- Virtual machines on cloud providers where the VM itself might be stopped or unreachable
- On-premise servers that might lose power or network connectivity
An ICMP check that fails tells you the problem is at the infrastructure level - don't waste time debugging your application code.
IoT and Edge Devices
Connected devices, point-of-sale terminals, kiosks, and edge computing nodes often don't run web servers. ICMP monitoring is sometimes the only way to verify these devices are online.
Database and Cache Servers
Your PostgreSQL, MySQL, Redis, or Memcached servers typically don't expose HTTP endpoints. While you can't verify the service is running with ICMP alone, you can verify the host is reachable - which narrows down the problem significantly when something goes wrong.
Connectivity Between Regions
ICMP monitoring between your own hosts (e.g., pinging your EU server from a US probe) tells you whether inter-region connectivity is healthy. Rising RTT between regions can indicate network congestion or routing issues before they affect users.
ICMP vs. HTTP Monitoring
These two approaches complement each other - they don't replace each other.
| ICMP (Ping) | HTTP | |
|---|---|---|
| What it checks | Host reachability | Application response |
| Network layer | Layer 3 (Network) | Layer 7 (Application) |
| Requires a web server | No | Yes |
| Detects application crashes | No | Yes |
| Detects network outages | Yes | Yes |
| Detects host-level failures | Yes | Yes |
| Response content validation | No | Yes |
| Measures application latency | No | Yes |
| Measures network latency | Yes | Partially (includes application processing time) |
| Works on any networked device | Yes | Only on HTTP servers |
The ideal setup: Use HTTP monitoring for your applications and APIs. Use ICMP monitoring for infrastructure that doesn't serve HTTP - network devices, database servers, edge devices, and bare metal hosts.
Key Metrics to Watch
Round-Trip Time (RTT)
RTT tells you how long a packet takes to travel to the host and back. A baseline RTT depends on geographic distance:
| Route | Typical RTT |
|---|---|
| Same data center | < 1ms |
| Same region (e.g., US East) | 1–10ms |
| Cross-country (e.g., US East → US West) | 40–80ms |
| Intercontinental (e.g., US → Europe) | 80–150ms |
| Global (e.g., US → Asia-Pacific) | 150–300ms |
What matters isn't the absolute number - it's the trend. A server that normally responds in 5ms and suddenly takes 50ms has a network issue, even if 50ms is technically fine in absolute terms.
Packet Loss
Any sustained packet loss above 0% is a problem. Brief spikes can be normal (network congestion, route changes), but consistent packet loss indicates:
- Network congestion - The path between the probe and the host is overloaded
- Hardware issues - A failing network interface, bad cable, or degraded switch port
- ISP problems - An upstream provider is dropping traffic
- DDoS mitigation - A DDoS protection system might be dropping ICMP packets (see caveats below)
Jitter
Jitter is the variation in RTT between consecutive pings. High jitter (e.g., responses alternating between 5ms and 200ms) indicates an unstable network path, even if the average RTT looks acceptable. This is especially important for real-time applications like VoIP or video conferencing.
Caveats and Limitations
Some Hosts Block ICMP
Many cloud providers, firewalls, and security policies drop ICMP packets by default. A host that doesn't respond to ping isn't necessarily down - it might be configured to ignore ICMP.
Before setting up ICMP monitoring, verify that the target host responds to ping. If it doesn't, HTTP or TCP port monitoring is a better choice.
ICMP Doesn't Verify Application Health
A host can respond to ping while every service on it is crashed. ICMP only tells you the network stack is responding - not that your database, web server, or application is running.
Always pair ICMP monitoring with application-level checks for services that have them.
Rate Limiting
Some networks rate-limit ICMP traffic. If your monitoring sends pings too frequently, responses might be delayed or dropped - creating false positives. A check interval of 30 seconds to 1 minute is reasonable for most use cases.
NAT and Private Networks
ICMP monitoring only works for publicly reachable hosts. Devices behind NAT or on private networks can't be pinged from external monitoring probes. For these, you'd need an internal monitoring agent or heartbeat-based monitoring.
Setting Up ICMP Monitoring
The setup is straightforward:
- Enter the host IP or hostname - The target you want to monitor
- Set the check interval - 30 seconds to 2 minutes, depending on criticality
- Configure alert thresholds - Alert on unreachability, high RTT, or packet loss above a threshold
- Set up alert routing - Where notifications should go when the host becomes unreachable
For most infrastructure monitoring, ICMP checks are set-and-forget. The host either responds or it doesn't. There's no content to validate, no status codes to interpret, and no application logic to consider.
Putting It Together
A well-structured monitoring setup uses both ICMP and HTTP checks, each for what they do best:
- HTTP for websites, APIs, health endpoints, and anything that serves web traffic
- ICMP for routers, switches, firewalls, database servers, bare metal hosts, and edge devices
- Heartbeat for cron jobs, background workers, and processes that don't accept inbound connections
- SSL/Domain for certificate and registration expiry
Each protocol covers a different blind spot. Together, they give you full-stack visibility from the network layer up to the application layer.