Skip to main content
Monitoring as Code: Learn more about the ICMP Monitor Construct.

​
What are ICMP Monitors?

ICMP monitors check if a host is reachable by sending ICMP Echo Requests (pings). Typical use cases include:
  • Verifying reachability for servers, load balancers, or network appliances that don’t expose HTTP endpoints or open TCP ports
  • Detecting network-level outages before they’re visible via HTTP endpoints
  • Monitoring latency across regions to identify geographic performance issues
  • Tracking packet loss to catch network quality degradation early

​
How do ICMP monitors work?

ICMP monitors perform ping tests:
  • Hostname resolution: If a hostname is provided, Checkly resolves it to an IP address
  • Ping execution: Multiple ICMP Echo Request packets (configurable from 1–50, default: 10) are sent from your configured locations, with a 500 ms interval between each ping
  • Response validation: ICMP Echo Reply packets are received. Round-trip latency and packet loss are measured and evaluated against your configured assertions
For example, pinging checklyhq.com with 3 pings returns: 
PING checklyhq.com (18.239.105.69): 56 bytes of data
64 bytes from 18.239.105.69: icmp_seq=0 ttl=247 time=6.6 ms
64 bytes from 18.239.105.69: icmp_seq=1 ttl=247 time=49.8 ms
64 bytes from 18.239.105.69: icmp_seq=2 ttl=247 time=6.6 ms

--- checklyhq.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
round-trip min/avg/max/stddev = 6.573/20.993/49.812/24.958 ms
The response appears on the results page as both raw output and parsed JSON. You can use it as a reference to define assertions for expected values.

​
ICMP Monitor Results

Select a specific check run to inspect its results:
ICMP monitor results page
  • Summary: Shows the target (hostname or IP), the monitor state (passed, degraded or failed), and average latency
  • Error details: If a run fails, you’ll see the error status code and message to help diagnose what went wrong
  • Response metrics: Network metrics collected during the run:
    • Packet info: packets sent, packets received, packet loss, and packet size
    • DNS resolution time: how long it took to resolve the hostname to an IP address
    • Latency: min, max, avg, and std dev of round-trip times (RTT) across all received packets
  • Response payload: Shows the raw ping result. Also available as parsed JSON
The monitor’s overview page aggregates historical run data, allowing you to analyze latency and packet loss trends over time.
ICMP monitor chart showing a breakdown of latency metrics and packet loss over time
Learn more in our documentation on Results.

​
Troubleshooting Common Issues

Symptom: ICMP monitor shows complete packet loss, but the website/API works fineRoot cause:
  • Many organizations block ICMP echo request packets at the firewall, load balancer, or host level as a security measure
How to detect and fix:
  1. Verify HTTP connectivity: Create an API or URL monitor for the same hostname to confirm it’s reachable
  2. Check both protocols: Test both IPv4 and IPv6, some hosts allow ICMP on one protocol but not the other
  3. Confirm with infrastructure team: Ask if ICMP is intentionally blocked in security policies
When to use a different monitor type: If ICMP is deliberately blocked, use TCP, URL, or API checks instead to verify availability at the application layer
Symptom: ICMP monitor shows high latency or packet loss from certain locations but not othersRoot causes:
  • Geographic routing: Network paths vary by region, some routes may be congested
  • Transit provider issues: Problems with specific ISPs or peering connections
  • Rate limiting: Some hosts rate-limit ICMP responses, affecting distant locations more
How to detect and fix:
  1. Compare across locations: Run monitors from multiple regions to identify which paths are affected
  2. Monitor trends over time: Check if issues are persistent or intermittent
  3. Cross-reference with other monitor types: Compare ICMP latency with TCP/HTTP latency from the same locations
  4. Use latency assertions: Set region-specific assertions, e.g., latency.avg less than 50ms for nearby regions, 200ms for distant ones
Investigation tip: Persistent high latency from a specific region often indicates routing issues with your hosting provider or CDN configuration