Ping (ICMP) monitors

A Ping (ICMP) monitor sends a few ICMP echo requests to a host on a schedule and answers two questions: is the host answering at all, and how healthy is the path to it? If the host stops replying (or loses more packets than you allow) twice in a row, the monitor goes Down, an incident opens, and your alerts fire.

Use it for infrastructure that has an IP address but nothing to fetch:

• Network gear — routers, firewalls, switches with a management IP
• VPN endpoints and gateways — site-to-site tunnels, bastion hosts
• Bare-metal and VM hosts — to know the box itself is reachable, independent of the services on it

Ping tells you the host is there. It can't tell you a website or database on it is working — the kernel answers ICMP even when nginx is dead. Pair it with an HTTP uptime monitor or a Port (TCP) monitor for the services themselves.

ICMP is often blocked. Many cloud security groups, firewalls and hosting providers drop or rate-limit ping by default, so a perfectly healthy server may never answer. If the host serves a known TCP port (443, 22, 5432…), a Port check on that port is usually the more reliable signal.

Create a ping monitor

1. Go to /monitors and click to create a monitor (or open /monitors/create directly).
2. Fill in the shared fields:
   • Project — which project the monitor belongs to.
   • Name — a label, e.g. "Office edge router".
   • Type — choose Ping (ICMP) (under Infrastructure). The type is fixed after creation.
   • Hostname or IP address — a bare hostname or IP, e.g. gw.example.com or 198.51.100.20. No http://, no :port, no path — ICMP has no ports. Use an IPv4 address or a hostname with an IPv4 (A) record; IPv6-only targets depend on the probe's IPv6 connectivity and may report "Network unreachable".
   • Check interval — every 1 minute up to every day, subject to your plan's minimum.
   • Ownership attestation — tick "I'm authorized to monitor this target."
3. Adjust the ping settings if you need to and save. The first check runs on the next scheduler tick.

Ping-specific fields

• Pings per check (1–5, default 3) — how many echo requests are sent each time the check runs.
• Max packet loss (%) (0–100, default 100) — loss above this marks the check as failed. The default of 100 means "any reply counts as up". Set it to 50 to fail a 3-ping check when two or more pings are lost, or 0 to require every ping to come back.

How a check runs

1. The hostname is resolved through the SSRF guard: DNS is resolved first, and hosts that resolve to private, loopback, link-local, cloud-metadata or other reserved addresses are rejected before anything is sent. When a hostname has both IPv4 and IPv6 addresses, the IPv4 address is pinged.
2. CompleteStatus sends the configured number of ICMP echo requests to that exact resolved IP, one per second, waiting up to 2 seconds for each reply (the whole check is time-boxed).
3. If no reply comes back at all, the ping is retried once within the same check before it counts as a failure.
4. The check passes when at least one reply came back and packet loss is within your threshold.

Checks currently run from a single region (US East). A network problem between our probe and your host looks the same as your host being unreachable, so confirm from a second vantage point (e.g. mtr) before calling your provider. Ping monitors are not yet available from additional monitoring locations.

Reading the results

The monitor page shows a Ping panel for the latest check:

• Replies — replies received out of pings sent, e.g. 3 / 3.
• Packet loss — the percentage lost this check, next to your threshold.
• RTT avg and RTT min / max — round-trip times in milliseconds.
• Resolved IP — the address that was actually pinged.
• On failure, the reason — e.g. No ICMP replies — host down or ICMP blocked, or Packet loss 67% exceeds the 50% threshold.

The average RTT feeds the latency chart and the anomaly baseline, so a path that slowly degrades (a congested link, a routing change) shows up as a rising trend — and can alert as an anomaly — before the host goes down.

Alerting

Ping checks feed the same state machine as every other monitor type: two consecutive failures are required to confirm DOWN. The first failed check is recorded as unconfirmed; if the next one also fails, the monitor goes Down, an incident opens with the failure reason as its cause, and your down alert rules fire. Recovery flips it back to Up, resolves the incident, and sends recovery alerts.

New ping monitors get a default alert rule for down, up and anomaly (unusual round-trip time). Add more on the monitor page — see Alert channels.

Troubleshooting

• Never answers, but the server is fine — ICMP is blocked somewhere on the path (a cloud security group, a host firewall, or the provider). Allow inbound ICMP echo requests (type 8 on IPv4; ICMPv6 echo request on IPv6) from the CompleteStatus probe, or switch to a Port check.
• Occasional single lost ping — routers often deprioritise ICMP. Keep the threshold at 100% ("any reply is up") or around 50% rather than 0% unless the path is known to be clean.
• "Blocked" or SSRF errors — the host resolved to a private or internal address (e.g. 10.x.x.x, 192.168.x.x, 127.0.0.1). CompleteStatus refuses to probe private networks by design. For hosts on a private network, a heartbeat monitor pinged by a local script is the right pattern.
• Validation says "not a URL" or "no ports" — enter just the host: example.com, not https://example.com or example.com:443. To check a specific TCP port, use a Port monitor.

Related guides

• Port (TCP) monitors — the more reliable check when ICMP is filtered.
• HTTP uptime monitors — the state machine and incident lifecycle in full.
• Importing monitors — UptimeRobot and Pingdom ping monitors import as Ping (ICMP) monitors.
• Ping vs HTTP checks — what "up" actually means at each layer.