What ping monitoring is good for
Ping monitoring answers the most basic question about a host: is it reachable on the network? An ICMP echo request goes out, and if a reply comes back the host is up. Because ping does not depend on any application, it is the clearest signal that a machine or network link is down.
Good uses for a ping monitor:
- Servers and VPS instances, as a base layer under your website and port monitors.
- Office routers and firewalls with a static public IP, to know when a site loses its internet connection.
- Network equipment such as VPN gateways that do not run a web server.
- Upstream providers, to see whether a slowdown is your server or the network in between.
Ping has limits. A server can reply to ping while its web server is crashed, so ping should complement, not replace, website and port checks. And some hosts and cloud providers block ICMP by default; if a host never replies, use a TCP port monitor instead.
Ping monitors target public hosts and IP addresses only. Private addresses such as 192.168.x.x or 10.x.x.x cannot be monitored directly; use a heartbeat from inside the network for those.
Using ping as a parent monitor
On the Team plan, a ping monitor works well as the parent in a monitor dependency, so when a whole server goes offline you get one alert instead of one per service. Monitor dependencies suppress alerts for child monitors while their parent is down.
For example, a single VPS might run a website, an API and a mail server:
| Monitor | Type | Role |
|---|---|---|
| vps-1.example.com | Ping | Parent |
| https://example.com | HTTP(S) | Child |
| https://api.example.com/health | API | Child |
| mail.example.com:587 | SMTP | Child |
If the VPS loses network connectivity, the ping monitor goes down and alerts are sent for it, while the three child monitors stay quiet. The on-call engineer immediately knows the problem is the host or its network, not three separate applications.
If only the website fails while ping still succeeds, you know the server is reachable and the problem is in the application layer. That distinction alone can save a lot of time early in an incident. Read more about dependencies and escalation in incident management.
Reading round-trip times
Each ping check records the round-trip time, so ping monitors double as a simple latency history for the network path to your host. Sudden jumps usually point to routing changes, congestion or an overloaded host.
Things to look for in the history:
- A step change that stays, often a routing change at your provider or a host migration.
- Daily patterns where latency rises at busy hours, which can indicate congestion on a shared link.
- Spikes followed by failures, which can precede a host becoming unreachable under load.
Keep in mind that checks currently run from one probe location, so round-trip times reflect the path from that location to your host, not from every user's location. Additional probe regions are planned.
Aggregated latency history is kept for 180 days on Starter and 395 days on Team, and raw results for 72 hours and 7 days respectively. Availability reports, including ping monitors, can be exported as CSV, and scheduled weekly or monthly email reports are available on both plans.
Set up a ping monitor
A ping monitor needs only a public hostname or IP address.
- Sign in on Starter or Team, or start the 14-day Team trial, and create a new monitor with the type Ping.
- Enter the public hostname or IP address, such as
vps-1.example.comor203.0.113.10. - Set the interval: down to 60 seconds on Starter or 30 seconds on Team.
- Choose alert channels and tags.
- Check that the first result shows a round-trip time. If the host never replies, ICMP may be blocked; use a TCP port monitor instead.
If you are moving from Uptime Kuma, ping monitors in a JSON backup import directly along with HTTP, port, DNS, push and gRPC monitors.
Give ping monitors clear names that identify the host rather than the service, such as the server hostname, so an alert immediately tells you which machine is affected. Tag them by provider or data center too, so you can see at a glance whether an outage is limited to one host or affects everything at a provider.
What's included on each plan
Ping monitoring is part of Starter and Team; on Free, use TCP port checks for host reachability.
| Free | Starter | Team | |
|---|---|---|---|
| Ping (ICMP) monitors | No | Yes | Yes |
| TCP port monitors | Yes | Yes | Yes |
| Fastest interval | 5 minutes | 60 seconds | 30 seconds |
| Monitor dependencies | No | No | Yes |
| Uptime and latency history | 30 days | 180 days | 395 days |
If you are on Free and need to know whether a host is reachable, a TCP port monitor on a port the host always serves, such as 443 or 22, is a good substitute. It also works on hosts that block ICMP.
Starter is the entry point for ping, with 60-second checks and 180 days of latency history. Team adds 30-second checks and monitor dependencies, which is where ping monitors become most valuable: as the parent of every service on a host, they keep a single server outage from flooding your channels. See the pricing page for all limits.
