Ping monitoring
Network-layer reachability for hosts that don't speak HTTP
ICMP echo checks for servers, network devices and anything that doesn't speak HTTP. Every monitored region pings your host, and multi-region consensus means a single bad peering link can't fake an outage.
ping -c 3 db.example.com · Ashburn probe
PING db.example.com (203.0.113.24): 56 data bytes 64 bytes from 203.0.113.24: icmp_seq=0 ttl=54 time=7.9 ms 64 bytes from 203.0.113.24: icmp_seq=1 ttl=54 time=8.2 ms 64 bytes from 203.0.113.24: icmp_seq=2 ttl=54 time=8.0 ms --- db.example.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss rtt min/avg/max = 7.9/8.0/8.2 ms
How it works
ICMP echo from every region, every check
Each monitored region sends three ICMP echo packets to your host every check interval. We record success the moment at least one packet returns, along with the average round-trip latency. Every regional result is logged so you can prove reachability per region in client reports.
Incidents are opened only when a majority of regions report failure at the same time, and they close only after every region recovers. The same multi-region consensus model we use for HTTP uptime, applied to the network layer.
- Three ICMP echo packets per region per check
- Average round-trip latency recorded per region
- Majority-region consensus before any alert fires
db.example.com · last check
Features
Reachability the way it should work
Multi-region consensus
ICMP echo from every monitored region. A majority must report failure before an incident opens, and every region must recover before it closes, so a single bad peering link doesn't wake you up.
Built for non-HTTP hosts
Database servers, network appliances, IoT devices, internal infrastructure: anything that responds to ICMP but doesn't speak HTTP. Pair with an HTTP monitor on the same host to separate network failures from application crashes.
Latency per region
Every check records the average round-trip latency from each region. Spot regional network degradation before it becomes an outage and prove SLA performance to clients with regional latency history.
Why it matters
When HTTP isn't the question
Plenty of infrastructure doesn't speak HTTP. Database servers, network appliances, and bastion hosts all need monitoring, and pretending to send them HTTP requests tells you nothing useful.
ICMP
Layer 3 echo, the most universal reachability test
per plan
Your check interval is set by your plan, and runs from every monitored region
66%
Multi-region consensus threshold before an incident opens
0
False alarms from single-region peering blips
Database and cache hosts
Postgres, MySQL, Redis, MongoDB: none of them speak HTTP, but they all need to be reachable for your application to work. Ping confirms the host is alive on the network without exposing any service port to the public internet.
Network appliances
Routers, firewalls, switches, VPN concentrators, and IoT devices respond to ICMP but don't run web servers. Ping is the only universal reachability check that works across this class of infrastructure.
Network vs app failures
Pair a ping monitor with an HTTP monitor on the same host and you can tell network outages apart from application crashes at a glance. Ping fails plus HTTP fails means a network issue. Ping works plus HTTP fails means your app crashed.
When should I use ping monitoring instead of HTTP monitoring?
Use ping when the host doesn't run a web server: database servers, mail servers, routers, switches, IoT devices, or anything where the question is simply 'is it on the network?'. For sites that do speak HTTP, ping makes a useful companion check so you can tell a network outage apart from an application crash on the same host.
Why might ping fail when HTTP still works?
Some cloud providers (Azure VMs, certain AWS security groups, many corporate networks) block ICMP at the firewall by default. The host can still respond to HTTP/HTTPS requests while silently dropping ping packets. Before treating ping failures as a real outage, verify with a manual ping from a known-good network and confirm ICMP is allowed in your host's firewall rules.
How does multi-region consensus work for ping?
Every monitored region pings the host on its own schedule. An incident is opened only when a majority of regions report failure (2 of 3, 3 of 4, or 66% for 5+ regions) AND no region reports success at the same time. The incident closes only after every region is responding again. This eliminates false alarms from regional peering issues that don't affect the host itself.
What hosts can I ping?
Any public hostname or IP address. Private addresses (RFC1918 ranges like 10.x.x.x, 192.168.x.x, loopback addresses, and link-local) are refused because they're not reachable from our public probes. If you need to monitor internal infrastructure, the same monitor type can be run from a self-hosted Sentinel probe with private-IP blocking disabled.
Is ping monitoring available on the free plan?
Ping is available on the Basic plan and above, alongside DNS, domain expiration, TCP port and heartbeat/cron monitoring. The free plan covers HTTP/HTTPS uptime and JSON response assertions.
Is there a free trial?
Yes. Paid plans include a 14-day free trial (a card is required to start it), and you can cancel anytime.
Start monitoring your infrastructure
Ping monitoring for every host you operate, with multi-region consensus to silence the noise.
No card for the free plan · 14-day trial on paid plans · Cancel anytime