Ping monitor: continuous ICMP ping monitoring from 300+ locations

Ping is the oldest useful question on a network: I am sending you a small packet, please send it straight back. The protocol is ICMP, the packet type is an echo request, and the answer - an echo reply - tells you two things at once. That the host is reachable, and how many milliseconds the round trip took.

Ping monitoring, sometimes written ICMP monitoring, is that question asked on a loop. A monitoring service sends the echo requests for you, from outside your network, every few minutes, indefinitely - and does three things a person typing ping cannot. It keeps every result, so latency becomes a graph instead of a memory. It asks from several places at once, so you can tell a broken host from a broken route. And it tells somebody when the answers stop, which is the only part of monitoring that actually reduces downtime.

The reason ping monitoring survives in an era of elaborate observability stacks is that it costs almost nothing and needs nothing installed. There is no agent on the device, no SDK in your code, no port to open, no credential to rotate. If the thing has an address and answers ICMP, it can be monitored - which makes ping the natural monitor for the enormous category of network equipment that will never run a monitoring agent: routers, switches, firewalls, VPN endpoints, cameras, industrial gateways and appliances.

Most people arrive at ping monitoring from a ping test. Something felt wrong, they ran a free online ping test, and it either confirmed the problem or - more often, and more annoyingly - came back perfectly healthy because whatever went wrong had already gone away. That second outcome is the whole argument for monitoring. A one-off test can only ever describe the seconds it ran in. What you actually wanted was a continuous ping test: the same four packets, sent again and again without you, with somebody told when they stop coming back.

Both are useful and neither replaces the other. Keep the instant test for triage - it is the fastest way to answer "is this thing responding at all" while you are already in the middle of something. Use monitoring for the hosts whose failure has a cost, because for those, finding out late is the expensive part. The companion guide on how to read ping results covers round-trip time, packet loss and the classic surprises in more depth.

A check begins with a DNS resolution of your target. By default the checkpoint uses its own local resolver - which is deliberate, because it means the check exercises the same name lookup a real visitor in that region would get. You can override that with up to four resolver IPs of your own, pin the check to public-DNS-filtered locations, or declare which resolvers the answer is expected to come from.

Then it sends four ICMP echo requests to the resolved address, one after another, allowing one second for each reply. Every packet that answers contributes its round-trip time and the address that actually replied; every packet that does not contributes the reason it failed. The target can be a host name or a literal IPv4 or IPv6 address - a ping monitor is addressed at a host, so a URL is reduced to its host name and any path or port is ignored.

The verdict is deliberately not "one packet was lost, sound the alarm". The check passes when more than half the packets come back. And if most of them fail, HostTracker still does not conclude yet: it repeats the round against the next address the name resolved to, up to three candidates in total, recording each address that failed on the way. Only when no candidate answers does the check report down. One dead A record in a multi-address DNS answer therefore cannot take down a monitor for a service that is genuinely healthy - a failure mode that catches out a surprising number of simpler tools.

Notice what is not on that list: there is no packet-count or timeout dial to get wrong. Every ping monitor runs the same four-packet round, so results are comparable across your whole estate and across time, and nobody has to remember why one monitor was set to two packets in 2023.

1. Check the host answers ICMP at all. Run a free instant ping test against it first - it takes seconds, needs no login, and saves you from building a monitor that can only ever report down.
2. Add a monitor and choose Ping check as its type. The 30-day trial covers it: 100 monitors, every check type, no credit card.
3. Enter the target as a host name or an IP address. A ping monitor is addressed at the host, not at a URL - gateway.example.com or 203.0.113.10, not a page path.
4. Give it a short name. That name is what appears in alerts, reports and widgets, so "edge-router-fra" beats "Monitor 7" the first time it pages you at two in the morning.
5. Pick the interval - one minute for anything whose downtime is expensive, three minutes for a normal server, hours for something you only need to know has quietly died.
6. Choose the monitoring locations. The defaults cover Western Europe, Eastern Europe and North America; add the regions your users are actually in, and decide what should happen if a chosen region has no available checkpoint at check time.
7. Set the recheck strategy if the default does not suit. A majority verdict across several independent checkpoints is the default and is right for almost everything; stricter options exist for hosts where a false alarm is worse than a late one.
8. Subscribe the contacts that should be alerted, each with its own delay. Then save, and read the first few results while everything is healthy - that baseline round-trip time is what makes the first real anomaly obvious.

Two optional extras are worth knowing about. A ping monitor can carry an attached DNSBL check, which runs every twelve hours and tells you if the host's address has turned up on a DNS blacklist - useful on a mail relay or an outbound gateway. And expected IPs turn the monitor into a light DNS-integrity check as well: declare which addresses the name should resolve to, and anything else fails the check, which is how a hijacked or misconfigured record announces itself.

A failed check is a signal, not a conclusion. Before anything is called down, the check is re-run across additional independent checkpoints and the state change is confirmed only when a quorum agrees. The default is a majority verdict across up to seven agents with a minimum of three, so a single flaky checkpoint or one transient hiccup on one network path cannot manufacture an alert. If your host needs different treatment you can require full agreement in both directions, require it only for a down transition, require a specific number of agents to report down, or - for hosts where speed beats certainty - skip the recheck entirely.

Once the transition is confirmed, alerting follows the delay each contact chose: immediately, or only after 3, 5, 15, 30 or 60 minutes, or 3, 6, 12 or 24 hours of continuous failure. That ladder is what lets one monitor serve a whole escalation chain - the on-call engineer at zero, the team lead at thirty minutes, the account manager at six hours - without anybody configuring three monitors.

Alerts go out over the nine channels HostTracker supports: email, SMS, voice call, webhook, Slack, web push and the messengers Telegram, Discord and Viber. A recovery notice follows when the host starts answering again, and contacts whose delayed tier never came due are deliberately not told about a recovery they were never told about the failure of. Planned work is handled by maintenance windows, so a scheduled reboot does not spend its night calling people.

These three checks answer three different questions, and choosing the wrong one is the most common reason a monitor is either useless or permanently noisy. The short version: ping asks whether the host is there, a port check asks whether the service is listening, and an HTTP check asks whether the application is working.

In practice the strongest setups combine them. Ping the host every minute for the cheapest, fastest signal that the machine itself has gone; run an HTTP availability check on the site it serves so an application failure is caught even when the host is perfectly reachable; add a TCP port check on the specific service ports that matter. When the ping starts failing and the HTTP check fails at the same moment, you know it is the box. When only the HTTP check fails, you know the box is fine and the software is not - which is a two-second diagnosis you get for free simply from having both.

Ping is a narrow instrument, and knowing exactly how narrow is what stops it becoming the monitor that cried wolf.

• A host that blocks ICMP cannot be ping-monitored. This is the big one. Many servers, and most firewalls in front of them, drop echo requests as routine hardening while serving web traffic normally. Against such a host the monitor reports down permanently and means nothing. Test first, and if there is no reply, monitor it over HTTP or TCP instead.
• Ping up does not mean the service works. A machine can answer every packet while the web server has crashed, the database is refusing connections, the disk is full or the certificate expired an hour ago. Ping proves the box is on the network. It proves nothing else, and treating a green ping monitor as proof that a site is fine is how outages get discovered by customers.
• Ping requires ICMP-capable checkpoints. Raw ICMP is not permitted on every hosting platform, so ping checks are routed only to checkpoints whose host allows it. The eligible fleet is large and worldwide, but it is a subset - which is another reason to select monitoring regions deliberately rather than pinning a monitor to one exotic location.
• There is no latency threshold to alert on. A ping monitor's state is reachable or not reachable; round-trip time is recorded, charted and reported, but a slow reply is still a reply. If you need an alert on a response-time policy rather than on silence, that is what an HTTP check or a page-load timing check is for.
• ICMP is deprioritised on the way. Routers under load will drop or delay echo replies before they drop real traffic, so a small amount of loss or an odd latency spike on a ping graph can be the network protecting itself rather than a problem with your host. Sustained, growing or multi-location loss is the signal; one strange data point usually is not.
• Checkpoints are external. The checks come from the public internet, so a device on a private network with no public address cannot be reached this way. Internal targets are the job of the private-network check types instead.
• It is real traffic, however small. Four packets per check per location is negligible by any standard, but a very aggressive interval across a long list of regions is still a pattern that will appear in a strict intrusion-detection log. Size the location list deliberately.

The point of monitoring a host continuously rather than testing it occasionally is that the results accumulate into something a single test can never produce: a shape. Every check a ping monitor runs is kept, and the statistics view turns them into a response-time chart with the average, minimum, maximum and 95th-percentile round-trip time for whatever period you select.

That percentile is more useful than it sounds. An average hides the tail - a host that answers in 20 ms almost always and in 900 ms twice an hour still averages beautifully, while feeling terrible to use. The 95th percentile is where that kind of intermittent misery becomes visible, and where a gradual degradation over three weeks shows up as a trend line rather than as an accident you happen to notice.

Alongside it, a per-location breakdown reports the round-trip time each checkpoint measured. This is the diagnosis that a single-location tool cannot give you: if every region degrades together, the problem is at the host; if one region degrades alone, the problem is a route, and it is affecting exactly the users who sit behind it. Every confirmed state change is timestamped too, so uptime percentages and downtime history are computed rather than reconstructed, and downtime periods are attributable to the moment they began.

All of it can be shared. A monitor's statistics can be made publicly viewable without giving anybody access to your account - which is the difference between telling a hosting provider that their box keeps disappearing and showing them. Scheduled uptime reports can go out to the same contacts that receive the alerts, so the monthly summary arrives without anybody generating it.

HostTracker's fleet spans 300+ checkpoints across 158 cities, and a ping monitor runs from the pools you select rather than from one fixed place. This matters more for ping than for almost any other check type, because ping's primary output is a distance measurement. A round-trip time only means something relative to where it was measured from: 200 ms from Tokyo to a server in Frankfurt is physics, and 200 ms from Amsterdam to the same server is a problem.

Multi-location checking is also what makes the difference between "the host is down" and "the host is unreachable from one part of the internet". A routing failure, a peering dispute or a regional filtering policy produces exactly the symptom of an outage - for some users. A monitor running from a single point reports that as a global outage or misses it entirely, depending on which side of it that point sits. A monitor running from several continents shows you the map.

Because a chosen region can occasionally have no checkpoint free at check time, each monitor also decides what should happen in that case: wait for its own region, or let the check run from elsewhere so the schedule is never silently skipped. Pair the geography with the confirmation quorum described above and the result is a monitor that is both sensitive and quiet - it sees regional problems that a single vantage point misses, and it refuses to page anybody on the strength of one checkpoint's bad minute.

Start with the 30-day free trial: 100 monitors, every check type, no credit card. It is the honest way to find out whether your hosts answer ICMP consistently enough for ping to be the right monitor for them, and to see a month of latency data before deciding anything.

After that, the free plan keeps 2 monitors running on a 30-minute interval - enough to watch a home server, a personal site's host or a single piece of equipment indefinitely at no cost. Paid plans start at $5 a month for Personal, $14 for Webmaster and $29 for Business, with Enterprise beyond that; the higher tiers raise the monitor count, the contact count and the minimum check interval, so a one-minute ping is available where you need one. The pricing page has the full comparison.

Because a ping monitor is one of the cheapest checks to run, it is usually not the monitor you have to ration. The common pattern is a ping monitor on every host in the estate for the fast, cheap "is it there" signal, and richer HTTP or transaction checks reserved for the handful of user-facing flows where an application failure actually costs money.