Ping monitoring: check that any server or device is reachable
HTTP Status Code Checker
Free, no sign-up. We only fetch the public URL you enter.
Short answer
Ping monitoring sends ICMP echo requests to a server or network device at a fixed interval – typically every one to five minutes – and records whether an echo reply comes back and how long the round trip took. If several pings in a row stay unanswered within the timeout, the host is marked down and an alert goes out. It confirms that a machine is reachable on the network, not that the website or service on it works. monitordefend does not offer ping (ICMP) checks; it monitors websites over HTTP.
- Measures two things: reachability (up or down) and round-trip time in milliseconds.
- Works for anything with a reachable IP address that answers ICMP: servers, routers, switches, firewalls.
- Combine it with HTTP and port checks, because a host can answer ping while its services are down.
$ ping -c 4 203.0.113.10 64 bytes from 203.0.113.10: icmp_seq=1 ttl=57 time=18.4 ms 64 bytes from 203.0.113.10: icmp_seq=2 ttl=57 time=18.9 ms 64 bytes from 203.0.113.10: icmp_seq=3 ttl=57 time=21.2 ms 64 bytes from 203.0.113.10: icmp_seq=4 ttl=57 time=18.6 ms 4 packets transmitted, 4 received, 0% packet loss rtt min/avg/max/mdev = 18.4/19.3/21.2/1.1 ms
Ping is the oldest and simplest availability test on the internet: send a small packet to a machine and wait for it to answer. Ping monitoring turns that one-off test into a continuous watch over servers, VPS instances, routers, firewalls and other network devices, so you learn about an unreachable host or a jump in latency before your users or colleagues do. This guide explains how ICMP monitoring works, which metrics it produces, what a good ping response time looks like, how to set it up with standard tools and where its limits are compared with website and port monitoring.
What is ping monitoring?
Ping monitoring is the continuous, automated version of the ping command. A monitoring system sends a small ICMP echo request to a target – an IP address or a hostname – at a fixed interval and waits for the matching echo reply. If the reply arrives, the target is reachable and the system records how long the round trip took. If no reply arrives within the timeout window, the check fails, and after a configurable number of failures the target is considered down and someone is notified.
Because ICMP is part of the IP stack itself, almost every networked device can answer a ping without any extra software: physical servers, virtual machines and VPS instances, cloud hosts, routers, switches, firewalls, load balancers, NAS boxes, printers and IoT devices. That makes ping monitoring the most universal availability check there is, and usually the first one administrators set up for infrastructure that has no website or API of its own.
How ICMP ping checks work
ICMP, the Internet Control Message Protocol, carries diagnostic and error messages between hosts. A ping uses two of its message types: the echo request (type 8) and the echo reply (type 0). The monitor sends an echo request with a sequence number and a small payload, the target’s network stack copies it into an echo reply and sends it back, and the monitor compares the timestamps. The difference is the round-trip time, usually reported in milliseconds.
- Echo request ICMP type 8 sent to the host
- Echo reply ICMP type 0 comes back
- Round trip Time measured in ms
- Verdict Up, slow or down
A sensible monitor never decides on a single packet. Packets get lost on busy links, and some routers deliberately rate-limit ICMP. Good ping monitoring therefore sends several packets per check, calculates packet loss, and confirms a failure with retries before it opens an incident. The result of each check is a small record – reachable or not, round-trip time, packet loss – and the series of those records is what makes trends and outages visible.
Many monitoring tools add a traceroute when a ping check fails. A traceroute sends packets with increasing time-to-live values and lists every router hop on the way, which shows whether the problem sits at your server, at your hosting provider or somewhere in a transit network between the monitor and your machine. That context turns a bare “host down” alert into something you can act on.
Monitor server availability
The most common use of ping monitoring is checking server uptime at the network level. You ping the public IP address of each server, and as long as replies come back, you know the machine is powered on, its network interface is up, its IP configuration is correct and the route to it works. When a server crashes, loses power, is disconnected by the hosting provider or has its network misconfigured during a change, the pings stop and you hear about it within minutes.
This is especially valuable for machines that do not expose a website: mail servers, database hosts, VPN gateways, build servers, game servers or backup targets. For these, a ping check is often the cheapest way to get basic availability monitoring without installing an agent. It is also a useful second signal for web servers: if your HTTP check fails but ping still answers, the machine is alive and the problem is in the web server or application; if both fail, look at the host or the network first.
- Ping the public IP of every server, VPS and cloud instance you are responsible for
- Use it as the baseline check for machines without a website or API
- Pair it with HTTP checks to tell host problems from application problems
- Monitor gateways and upstream routers to spot provider-side outages
Monitor server response time and latency
Every successful ping also produces a measurement: the round-trip time. Tracked over hours and days, that number tells you a lot about the network path to your server. A stable line means a healthy path. A sudden step up can mean traffic is being routed differently, a link is congested, the host is overloaded or a DDoS is filling its uplink. Gradual creep over weeks can point to a saturated connection that needs an upgrade.
The value of response time monitoring is that it often warns before a full outage. Packet loss and rising latency frequently precede a link going down entirely, so a monitor that alerts on “round-trip time above 150 ms for 10 minutes” or “packet loss above 20 %” gives you time to react. Keep thresholds relative to the normal baseline of each target rather than using one number for everything, because distance alone changes what normal looks like.
What is a good ping response time?
There is no single good ping; it depends mostly on the physical distance between the monitoring location and the target, plus the number of networks in between. Light in fibre travels roughly 200 kilometres per millisecond, so a round trip across an ocean can never be as fast as one within a city. As a rough guide, a few milliseconds is typical inside one data centre, under 50 ms within the same region, 50 to 150 ms across a continent or between neighbouring regions, and above 150 ms for intercontinental paths.
Values above roughly 300 ms deserve a look unless the distance explains them. More important than the absolute number is consistency. A server that normally answers in 20 ms and suddenly needs 200 ms has a problem, even though 200 ms would be acceptable for a server on another continent. Watch jitter – the variation between consecutive pings – as well: high jitter hurts real-time traffic such as voice and video more than a steady, slightly higher latency does.
| Round-trip time | Typical situation | What to do |
|---|---|---|
| Under 10 ms | Same data centre or city | Nothing – ideal |
| 10 – 50 ms | Same region or country | Healthy for most uses |
| 50 – 150 ms | Across a continent or between regions | Normal, watch the trend |
| 150 – 300 ms | Intercontinental paths | Expected for long distances |
| Over 300 ms | Congestion, overload or bad routing | Investigate unless distance explains it |
Monitor devices in your network
Ping monitoring is not limited to servers. Routers, core switches, firewalls, wireless access points, VPN concentrators, storage appliances and even printers answer ICMP, and a dead device in the middle of a network can take many services down at once. Pinging each key device lets you see immediately which part of the network has failed instead of chasing symptoms in every application behind it.
For devices that only have private addresses, an external monitoring service on the internet cannot reach them directly. The usual options are an internal monitoring tool inside the network, a small probe or agent that runs locally and reports outward, or exposing a single public endpoint such as the edge router. Whatever you choose, map dependencies: if the edge router is down, every device behind it will look down too, and you want one alert for the root cause rather than fifty for its consequences.
Ping monitoring vs. website and port monitoring
Ping answers one narrow question: does the host respond on the network? It says nothing about the web server, the application, the database or any other service running on that machine. A server can answer every ping while Nginx has crashed, PHP returns errors or the disk is full. That is why ping is a foundation, not a complete monitoring strategy.
Website monitoring sends real HTTP or HTTPS requests, checks the status code and measures how long the page takes to respond – it verifies that the site works for visitors. Port monitoring opens a TCP connection to a specific port, such as 443 for HTTPS, 22 for SSH, 25 or 587 for mail or 3306 for MySQL, and confirms that the service behind it accepts connections. A layered setup uses all three: ping for the host, port checks for each service and HTTP checks for anything users visit in a browser.
How to check your ping manually
Before automating anything, test from a terminal. On Linux and macOS, run ping followed by a hostname or IP address – for example ping -c 4 example.com – to send four packets and see the round-trip time of each plus a summary with packet loss and minimum, average and maximum latency. On Windows, ping example.com sends four packets by default; add -t to keep pinging until you stop it. For IPv6, use ping -6 on Windows and ping6 or ping -6 on Linux and macOS.
If the target does not answer, run traceroute (tracert on Windows) to see where the packets stop, and mtr on Linux for a combined, continuously updated view of latency and loss per hop. Always test from outside your own network as well, for example from a remote server, because a ping from the same LAN bypasses the firewall and routing that external users and monitors go through. If you need to work out IP ranges or subnet boundaries for a group of devices, an IP subnet calculator helps.
Set up ping monitoring in a few steps
Setting up ping monitoring is quick with almost any tool. The process looks the same whether you use a hosted service, an open-source system such as Zabbix, Nagios, Icinga, Prometheus with the blackbox exporter or Uptime Kuma, or a script on a spare server.
- Check 1: no echo reply within 5 s
- Check 2 and 3: still no reply – host marked down
- Alert sent to the on-duty admin
- Replies return, 0 % loss – host marked up
- Choose the targets: public IPs or hostnames of servers, gateways and key devices
- Allow ICMP echo requests from the monitoring IPs in every firewall and security group on the path
- Pick an interval – one to five minutes suits most infrastructure – and a timeout of a few seconds
- Require several failed checks or retries before an alert, to filter single lost packets
- Set latency and packet-loss thresholds based on each target’s normal baseline
- Route alerts to a channel someone watches, with recurring reminders for long outages
- Schedule maintenance windows so planned reboots do not page anyone
My server shows as down but it is up – why?
The most frequent cause of false “down” alerts in ping monitoring is ICMP being blocked. Many cloud providers block inbound ICMP by default, and host firewalls such as UFW, firewalld, iptables, nftables or Windows Defender Firewall often drop echo requests silently. The server is running perfectly, but the packets never get an answer. Check the cloud security group or network ACL (for example AWS security groups, Google Cloud firewall rules or Azure network security groups), then the host firewall, and allow ICMP echo requests at least from your monitoring service’s published IP addresses.
Other causes include ICMP rate limiting on busy routers, DNS returning a different IP than expected, a CDN or load balancer in front of the host that does not answer pings, and a problem on the monitor’s side of the network. Verify with a manual ping from an independent external machine. Checks from several locations help a lot here: if only one location reports the host as unreachable, the problem is probably a routing issue on that path, not your server.
Ping by IP address or domain name, IPv4 or IPv6
Most tools accept both raw IP addresses and hostnames. With a hostname, the monitor first resolves it via DNS and then pings the resulting address. That is convenient, but if the name points to a CDN, a load balancer or round-robin DNS, the resolved address can change between checks and you end up measuring different machines. For a precise picture of one specific server, ping its direct IP; for a picture of what users reach, ping the name – and consider monitoring both.
If your infrastructure is dual-stack, monitor IPv4 and IPv6 separately. The two protocols often take different routes, pass different firewall rules and fail independently. A missing ICMPv6 rule or a broken IPv6 route can leave a share of your users unable to connect while every IPv4 check stays green. Note that ICMPv6 is also essential for IPv6 itself to work, so blocking it entirely causes more problems than just failed pings.
Advanced features worth looking for
Beyond the basic up-or-down check, a few features decide whether ping monitoring is pleasant or noisy in daily use. Multi-location checks ping your host from several regions and only alert when more than one agrees, which removes most false alarms and reveals outages that affect only certain regions. Recurring notifications remind you while a host stays down, so an alert is not forgotten after the first message. Maintenance windows pause checks during planned work.
Also useful are configurable timeouts and retry counts, packet-loss thresholds, latency alerts relative to a baseline, traceroutes attached to failure alerts, dependency handling so a dead router does not trigger alerts for every host behind it, and alert channels that fit your team, from email to chat tools, SMS or phone calls. Many hosted tools include free ping monitoring with intervals of around five minutes and charge for shorter intervals, more locations or more channels.
Common ping monitoring mistakes
The classic mistake is treating a green ping as proof that everything works. It only proves the host is reachable. Pair every important ping check with an HTTP or port check for the service that actually matters. The second mistake is alerting on one lost packet: without retries and loss thresholds, ping monitoring generates noise that teaches people to ignore alerts.
Other mistakes include monitoring hostnames that resolve to changing addresses, forgetting IPv6, using the same latency threshold for nearby and distant targets, monitoring only from inside the network the target lives in, and never reviewing the history. The response time chart is one of the best early-warning signals you have; look at it whenever something feels slow, not only when an alert arrives.
Website monitoring with monitordefend
monitordefend does not offer ping, ICMP or network-device monitoring, and it does not check servers by IP address. It is a hosted monitor for websites: every five minutes from Germany it requests your homepage over HTTP, confirms a failure with a second attempt and records the response time, alongside daily broken-link crawls, sitemap and Google indexing checks, checkout and payment-page checks, and detection of suspicious changes such as new external scripts. Alerts are sent by email. If your concern is whether visitors can use your website, that complements the ping checks you run for your infrastructure.
Frequently asked questions
What is ping monitoring and how does it work?
Ping monitoring checks whether a server or device is reachable and how fast it answers. At each interval the monitor sends ICMP echo requests to an IP address or hostname; an echo reply means the host is up, and the round-trip time is recorded. If replies stay missing beyond the timeout and retries, the host is marked down and an alert is sent.
What metrics does ping monitoring measure?
Availability (does the host answer at all), round-trip time in milliseconds, and packet loss as a percentage of unanswered packets. Many tools also track jitter, the variation between consecutive round-trip times, and keep the history so you can spot slow changes before an outage.
What is a good ping response time?
It depends on distance. Under 50 ms is healthy within a region, 50 to 150 ms is normal across regions, and above 300 ms is worth investigating unless the target is very far away. A sudden jump from a stable baseline matters more than the absolute value.
What is the difference between ping monitoring and website monitoring?
Ping confirms the server is reachable on the network using ICMP. Website monitoring sends HTTP or HTTPS requests, checks the status code and measures load time, so it confirms the site actually works for visitors. A host can answer ping while its website is broken.
What is the difference between ping monitoring and port monitoring?
Ping checks the host; port monitoring checks a specific service on it by opening a TCP connection to a port such as 443, 22 or 3306. A server can answer ping while the database or mail service on it has stopped.
Which devices can I monitor with ping?
Anything with a reachable IP address that answers ICMP: physical and virtual servers, VPS and cloud instances, routers, switches, firewalls, access points and many appliances. For external monitoring the device must be reachable from the internet and ICMP must not be blocked.
Can I ping both an IP address and a domain name?
Yes. A domain name is resolved to an IP address before the ping. If the name points to a CDN or load balancer, the address may change between checks, so ping the direct IP when you want to watch one specific server.
Is ping monitoring free?
Free options exist: the ping command itself, open-source tools such as Zabbix, Nagios or Uptime Kuma, and hosted services with free tiers that ping every few minutes. Paid plans usually add shorter intervals, more locations and more alert channels.
How often should I ping my servers?
Every one to five minutes is enough for most infrastructure. Critical systems can be checked every 30 to 60 seconds, but always combine short intervals with retries so single lost packets do not cause alerts.
Does monitordefend offer ping monitoring?
No. monitordefend monitors websites over HTTP every five minutes from Germany and sends email alerts; it has no ICMP, ping or network-device checks.
Related pages
Know when your website stops working for visitors
Start for free and set up your first check in minutes.
Start for free