Ping is the simplest way to check if a machine is alive. Send an ICMP ECHO_REQUEST, wait for a response. If ECHO_REPLY arrives — machine is online. No need for HTTP server, no need for open ports, no need for authorization. Simply: is there network connectivity or not?
Sounds simple, but there's a catch. Ping is infrastructure monitoring, not service monitoring. Host can respond to ping (machine online) but database crashed, nginx returns 500, everything broke. Ping won't see that. That's why ping is used with TCP and HTTP checks for complete coverage.
How ICMP Ping Works
Ping Protocol: ICMP ECHO
ICMP (Internet Control Message Protocol) — network control protocol. It sits at the same layer as IP, used for diagnostics.
Ping packet structure:
- Type: 8 (ECHO_REQUEST)
- Code: 0
- Checksum
- Identifier (process ID)
- Sequence number (which ping in the series)
- Timestamp (when sent)
- Optional data payload
Response: host receives ECHO_REQUEST, sends ECHO_REPLY back with the same data.
Typical Ping Process
$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=12.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=12.4 ms
--- 8.8.8.8 statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/stddev = 12.2/12.35/12.5/0.13 msInterpreting Results
Latency (time): 12.3 ms = round-trip time. Normal is \<100ms locally, \<500ms intercontinental.
TTL (Time To Live): 119 = was 128 (Linux default), route passed through 9 hops. If TTL drops to 0 — packet lost (too many hops).
Packet loss: 0% = all 4 packets arrived. 25% = 1 of 4 lost. High packet loss (>5%) = network degraded.
Min/Avg/Max: variability. If max >> avg (12.2 vs 50ms) — network has jitter (quality unstable).
When Ping Monitoring Is Useful
Bare Metal Servers Without HTTP
Machine functions as gateway, firewall, or raw compute node. No web server, no TCP services. Only way to check if it's alive is ping.
IoT Devices and Embedded Systems
Router, smart sensor, industrial device. They can respond to ping but not have HTTP API. Ping verifies they're powered on and have network connectivity.
Network Health and Latency Tracking
Even if you monitor HTTP, it's useful to track ping latency separately. If your web application latency grows from 100ms to 300ms — that's a signal the network degraded (not the application).
Monitoring Infrastructure (Cloud Instances, VMs)
AWS EC2 instance, Google Compute Engine VM, Digital Ocean droplet. Even if the application crashes, the machine should still respond to ping. Ping confirms it's powered on and has network connectivity.
Diagnosing Network Issues
If HTTP check fails but TCP port opens, and ping responds slowly — the problem is network, not application. Ping helps narrow down the root cause.
When Ping Monitoring Is Not Enough
Ping Doesn't Catch Application Failures
Host responds to ping, but nginx returned 500, database is out of memory, application is hung. Ping shows everything OK, users see errors.
Solution: use HTTP health check or TCP check on top of ping.
Ping Doesn't Catch Service Port Failures
Machine is online and responds to ping, but specific port is closed. PostgreSQL crashed, but Linux kernel still running. HTTP server is off, but ICMP still responds. Ping won't catch these failures.
Firewalls Can Block ICMP
Many corporate firewalls block ICMP for "security". Host is accessible, but ping returns timeout. This creates false positive failures.
ICMP Packet Loss as Metric
What Packet Loss Means
0% packet loss: perfect, all packets arrived
< 1% packet loss: normal for internet, occasional drop
1-5% packet loss: noticeable, signal of degradation
5-10% packet loss: critical, applications notice (TCP retransmits)
10%+ packet loss: network basically broken, needs diagnostics
What Causes Packet Loss
Congestion (network overload): too much traffic, router buffers overflow. Packets dropped.
Physical issues: bad cable, interference, dying ethernet interface
Misconfiguration: MTU mismatch, jumbo frames incompatible
WiFi interference: if monitor is on WiFi, packet loss likely
Routing issues: bad path, BGP flapping
Firewall Blocks ICMP: What to Do
Diagnosis
If ping times out but you can SSH to the machine — ICMP is blocked:
# From your machine
$ ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
Request timeout
Request timeout
# But SSH works
$ ssh user@1.2.3.4
Connected!
# Conclusion: Firewall blocks ICMP, but allows TCP/22Solutions
Option 1: Open ICMP in Firewall
Ask admin to allow ICMP (Type 8 ECHO_REQUEST) inbound for monitor IP
Option 2: Use TCP/HTTP Check Instead of Ping
Monitor TCP port (port 22 for SSH, or application port) or HTTP endpoint
Option 3: Use Internal Monitoring
Deploy agent inside the network, it can ping internal hosts even if ICMP is blocked externally
Jitter: Variable Latency
Ideal network: all pings respond in exactly 12.0ms. Real network: some 12.0ms, some 12.5ms, sometimes spike to 50ms.
Jitter: stddev (standard deviation) in the ping example above = 0.13ms. Low jitter (good).
High jitter: 0.13ms vs 5.0ms stddev means latency is unstable. VoIP and video conferences suffer with jitter.
Low jitter: predictable latency, applications can plan timeouts better.
Ping Monitoring in AtomPing
Creating an ICMP Check
Type: ICMP (Ping)
Host: 1.2.3.4 or example.com
Timeout: 5 seconds (enough for internet ping)
Interval: 60 seconds (ping every hour or less frequently to save)
Regions: select multiple for global coverage
Packet count: usually 4 packets per probe
Combining Ping with Other Checks
For production-critical services — monitor with multiple methods:
ICMP Ping: infrastructure alive? (machine online, network working)
TCP Check: service listening? (port open, process running)
HTTP Check: service healthy? (app responding, dependencies OK)
Heartbeat: jobs running? (background work happening)
Outcomes:
✓ Ping, ✓ TCP, ✓ HTTP → everything good
✓ Ping, ✓ TCP, ✗ HTTP → application crashed
✓ Ping, ✗ TCP, ✗ HTTP → service down (port closed)
✗ Ping, - TCP, - HTTP → machine not reachable (network problem)
TTL and Traceroute Diagnostics
Ping shows TTL in the response. TTL (Time To Live) = how many hops a packet can make before being dropped.
Linux: default TTL = 64
Windows: default TTL = 128
Cisco: default TTL = 255
Example: Linux machine (TTL=64) sends packet. Response arrives with TTL=60. That means 4 hops (64-60=4).
Diagnostics: if TTL very low or variable — sign of unstable routing.
Ping vs Response Time Monitoring
Ping latency (ICMP round-trip) is often lower than HTTP response time (application processing). This is normal.
Ping latency: 12ms (just returns packet, no processing)
TCP latency: 15ms (TCP handshake)
HTTP response: 150ms (HTTP overhead + app processing)
Conclusion: ping = network baseline. HTTP = application performance. Difference shows where bottleneck is.
Common Ping Monitoring Mistakes
Mistake 1: Relying Only on Ping
Ping succeeds, but application crashed. Not sufficient monitoring.
Mistake 2: Assuming ICMP Blocked = Service Down
Firewall blocks ICMP, service works fine. False positive alert.
Mistake 3: Monitoring Cellular/WiFi Networks with Ping
WiFi packet loss is natural (5-10%), mobile networks too. Ping has many false positives. Use HTTP check instead of ping.
Mistake 4: Ignoring Latency Increase
Ping arrives in 50ms instead of normal 10ms. This signals network is overloaded. Don't wait for complete failure — this is a warning.
Ping vs Internal vs External Monitoring
Ping can be internal (from within VPC) or external (from internet).
External ping: verifies machine is accessible from internet (important for public-facing services)
Internal ping: verifies connectivity in VPC/network (important for databases, cache)
Recommendation: for production use both — external catches internet routing issues, internal catches internal network problems
ICMP Ping Monitoring Checklist
Goal: correctly defined? (infrastructure alive, not service-level)
Firewall: is ICMP allowed from monitor? If not — use TCP/HTTP check
Combination: ping + TCP + HTTP for defense-in-depth
Baseline latency: do you know normal ping time? (10ms? 100ms?)
Alert threshold: at what latency to alert? (2x normal?)
Interpretation: correctly understand results (ping OK ≠ service is healthy)
Related Articles
Complete Guide to Uptime Monitoring — overview of all check types
TCP Port Monitoring — more detailed service monitoring
Response Time Monitoring — application latency tracking
Internal vs External Monitoring — coverage strategies
ICMP Check — in AtomPing
FAQ
What is ICMP ping monitoring?
ICMP ping monitoring sends ECHO_REQUEST packets to a target host and measures response time. If the host responds with ECHO_REPLY, it's reachable. Ping measures network latency (round-trip time), packet loss, and whether the host is accessible. Unlike HTTP or TCP checks (which test a specific service), ping checks if the entire host is reachable from the network perspective.
How does ICMP ping work?
Ping uses Internet Control Message Protocol (ICMP). Monitor sends ECHO_REQUEST packet (type 8) with a sequence number and timestamp. Target host receives it and immediately responds with ECHO_REPLY packet (type 0) containing the same data. Monitor measures round-trip time (latency). If no reply arrives within timeout (usually 3-5 seconds), the host is unreachable.
When is ICMP ping useful?
Ping checks infrastructure reachability: is the host powered on? Is the network path open? For bare metal servers, IoT devices, or routers without HTTP services, ping is the only available check. Ping also detects network degradation (packet loss, high latency). Not useful for detecting service-level failures (web server returns 500, database is out of memory) since ping only checks network layer.
Why do firewalls block ICMP ping?
Some systems block ICMP for security (prevent network reconnaissance). Others allow ping for diagnostics. Many cloud providers (AWS, Azure) allow outbound ping but block inbound to prevent abuse. If your ping check shows timeout but the host is up, firewall is likely blocking ICMP. Workaround: use TCP or HTTP check on a known port instead.
What's the difference between latency and packet loss in ping?
Latency (round-trip time) is how long the ping takes (milliseconds). Normal is <100ms local, <500ms intercontinental. Packet loss is percentage of packets that didn't return. 0% = all replies received. 10% = 1 in 10 packets lost. Both indicate network problems: high latency = congestion, packet loss = physical issues or overload.
How is ICMP ping different from TCP/HTTP monitoring?
ICMP ping checks if a host is reachable (network layer). TCP checks if a specific port accepts connections (transport layer). HTTP checks if a service responds correctly (application layer). A host can pass ping (reachable) but fail TCP (port closed), and pass TCP but fail HTTP (service not responding). Use ping for infrastructure, TCP for services, HTTP for applications.