Before HTTP. Before DNS lookups. Before TLS handshakes. There's ping — the simplest possible question you can ask a server: "Are you there?"
Ping monitoring sends ICMP packets to a host and measures whether they come back and how long the round trip takes. It's the most fundamental network check, and it catches problems that higher-level monitors can't see.
This guide explains how ping works, what the numbers mean, when to use it, and how to set up effective ping monitoring for your infrastructure.
What Is Ping?
Ping is a network utility that sends ICMP (Internet Control Message Protocol) Echo Request packets to a target host and waits for Echo Reply packets back. It measures two things:
- Reachability — Did the host respond at all?
- Round-trip time (RTT) — How long did the response take?
When you run ping google.com in a terminal, you're sending a tiny packet to Google's servers and timing how long it takes to get a reply. The result looks something like:
64 bytes from 142.250.80.46: icmp_seq=1 ttl=117 time=12.3 ms
64 bytes from 142.250.80.46: icmp_seq=2 ttl=117 time=11.8 ms
64 bytes from 142.250.80.46: icmp_seq=3 ttl=117 time=13.1 ms
Each line is one packet sent and received. The time value is the round-trip latency in milliseconds.
Key Metrics: Latency and Packet Loss
Latency (Round-Trip Time)
Latency is the time it takes for a packet to travel from the source to the destination and back. It's measured in milliseconds (ms).
| Latency | What it means |
|---|---|
| < 20 ms | Excellent — same region or nearby data center |
| 20–50 ms | Good — typical for same-continent connections |
| 50–100 ms | Acceptable — cross-continent or multiple network hops |
| 100–200 ms | Noticeable — users may feel delays in real-time apps |
| > 200 ms | Problematic — indicates routing issues or distant servers |
Latency isn't just a number. It affects every request your users make. A 50 ms increase in latency might not matter for a blog, but it's significant for a real-time dashboard, API, or video call.
What causes high latency:
- Geographic distance — Light through fiber takes about 5 ms per 1,000 km. A server in Europe pinged from Australia will inherently have ~150 ms latency.
- Network congestion — Overloaded routers and switches queue packets, adding delay.
- Routing inefficiency — Packets sometimes take indirect paths through multiple autonomous systems.
- Server load — An overloaded server may delay ICMP responses.
- Packet size — Larger packets take longer to transmit, though for ping this is usually negligible.
Packet Loss
Packet loss is the percentage of sent packets that never receive a reply. Even 1% packet loss is a problem.
| Packet loss | What it means |
|---|---|
| 0% | Healthy — all packets returned |
| 0.1–1% | Minor — occasional drops, usually transient |
| 1–5% | Significant — users will notice degraded performance |
| 5–20% | Severe — connections become unreliable |
| > 20% | Critical — effectively unreachable for many applications |
What causes packet loss:
- Network congestion — Routers drop packets when buffers overflow.
- Faulty hardware — Bad cables, failing NICs, or degraded switches.
- Wireless interference — Wi-Fi and cellular connections are inherently less reliable.
- ISP issues — Upstream provider problems that affect a specific route.
- Rate limiting — Some servers intentionally drop ICMP packets to reduce load.
- Firewall rules — Security policies may block or throttle ICMP traffic.
Jitter
Jitter is the variation in latency between packets. If one packet takes 10 ms and the next takes 80 ms, that's high jitter. It matters less for websites but is critical for VoIP, video streaming, and real-time applications.
How ICMP Works (The Protocol Behind Ping)
ICMP is part of the Internet Protocol suite, sitting at the network layer (Layer 3). Unlike TCP or UDP, ICMP doesn't carry application data — it's used for network diagnostics and error reporting.
The ping exchange
- The monitoring server sends an ICMP Echo Request (Type 8) to the target host.
- The target host receives the packet and sends back an ICMP Echo Reply (Type 0).
- The monitoring server measures the time between sending and receiving.
If no reply arrives within the timeout period, the packet is considered lost.
Why ICMP is different from TCP/HTTP
| ICMP (Ping) | TCP (Port Check) | HTTP | |
|---|---|---|---|
| Layer | Network (Layer 3) | Transport (Layer 4) | Application (Layer 7) |
| What it proves | Host is reachable on the network | A specific service is accepting connections | An application is responding correctly |
| Overhead | Minimal — tiny packets | Low — TCP handshake only | Higher — full request/response |
| Can be blocked | Yes — firewalls often block ICMP | Less commonly | Rarely |
Each layer builds on the one below. If ping fails, TCP and HTTP will also fail. But ping succeeding doesn't guarantee the application is healthy — it only proves the host is reachable at the network level.
When to Use Ping Monitoring
Network reachability checks
Ping is the fastest way to verify a host is online and reachable. It answers the most basic question: can packets reach this server and come back?
Latency baseline and trending
By pinging a host continuously, you build a latency baseline. When latency spikes above normal, it's an early warning of network problems — often before application-level monitors detect anything.
Router and switch monitoring
Network equipment (routers, switches, firewalls) often doesn't run HTTP servers. Ping is the standard way to monitor their availability.
Multi-hop diagnostics
Combined with traceroute, ping helps identify which network hop is causing latency or packet loss. This is essential for diagnosing routing problems between your users and your servers.
Upstream provider monitoring
Ping your ISP's gateway, your DNS provider, your CDN's edge nodes. If latency to your CDN doubles overnight, you want to know before users start complaining about slow page loads.
When NOT to use ping
- Application health — Ping can't tell you if your web app is returning errors. Use HTTP monitoring for that.
- Hosts that block ICMP — Some cloud providers and firewalls drop ICMP traffic by default. A "failed" ping doesn't mean the host is down if ICMP is blocked.
- Service-specific checks — To verify a database or cache is accepting connections, use TCP port monitoring instead.
Ping Monitoring vs. Other Monitoring Types
| Monitoring Type | Layer | What It Catches | Blind Spots |
|---|---|---|---|
| Ping (ICMP) | Network | Host unreachable, high latency, packet loss | Application errors, service-level failures |
| TCP port | Transport | Service not accepting connections | Application logic errors |
| HTTP | Application | Server errors, wrong responses, slow pages | Network-level issues masked by CDNs |
| DNS | Application | Resolution failures, wrong records | Post-resolution connectivity |
A complete monitoring setup uses multiple layers. Ping catches the network problems that TCP and HTTP monitors miss — and it catches them first, because there's less overhead.
Common Causes of Ping Failures
1. Host is genuinely down
The server crashed, lost power, or the OS hung. No network service is running. This is the simplest failure mode and exactly what ping is designed to detect.
2. Network path failure
The host is running fine, but the route between the monitoring server and the target is broken. A failed router, a cut fiber, or a BGP misconfiguration can make a perfectly healthy server unreachable from specific locations.
3. ICMP is blocked
Many cloud environments (AWS security groups, for example) block ICMP by default. The host is up and services are running, but ping fails because the firewall drops the packets. This is a configuration issue, not an outage — but your monitoring needs to account for it.
4. Rate limiting
Some servers rate-limit ICMP responses. If your monitoring pings too frequently, responses may be dropped. This appears as intermittent packet loss.
5. DDoS attacks
During a DDoS attack, network links become saturated. Ping packets are dropped or delayed because routers can't handle the volume. Ping monitoring catches this as sudden latency spikes and packet loss.
Ping Monitoring Best Practices
Set a latency baseline first
Before alerting on high latency, monitor the host for a few days to establish a normal range. A server in a distant region might always have 120 ms latency — alerting at 100 ms would generate constant noise.
Alert on packet loss, not individual timeouts
A single dropped ping is rarely meaningful. Alert when you see sustained packet loss — for example, 3 or more consecutive failures, or >5% loss over a 5-minute window.
Monitor from multiple locations
Latency from your office to your server is not the same as latency from your users to your server. Use multi-region monitoring to measure what your actual users experience.
Combine with higher-layer checks
Ping tells you the host is reachable. TCP tells you the service is accepting connections. HTTP tells you the application is working. Use all three for complete visibility:
- Ping fails → Network or host problem
- Ping OK, TCP fails → Service crashed but host is up
- Ping OK, TCP OK, HTTP fails → Application error
Don't ping hosts that block ICMP
If a host blocks ICMP, a failing ping doesn't mean downtime. Verify ICMP is allowed before adding a ping monitor. Use TCP or HTTP checks for hosts where ICMP is blocked.
Track trends, not just thresholds
A gradual increase in latency over weeks is more important than a one-time spike. Trending helps you catch infrastructure degradation — a filling disk, a failing NIC, or a network path change — before it causes an outage.
How Webalert Monitors Ping
Webalert includes ICMP ping monitoring alongside HTTP, TCP, and DNS checks:
- Continuous ping checks — Monitor any host by IP address or hostname with configurable check intervals.
- Latency tracking — See round-trip time graphs over time to spot trends and degradation.
- Packet loss detection — Get alerted when packet loss crosses your threshold.
- Multi-region pings — Check reachability from multiple global locations to catch region-specific network issues.
- Smart alerting — Alerts fire after consecutive failures, reducing noise from transient blips. Notifications via email, SMS, Slack, Discord, or webhooks.
- Unified dashboard — View ping, HTTP, TCP, and DNS monitors side by side. When something fails, see exactly which layer has the problem.
See features and pricing for the full list of monitoring capabilities.
Summary
Ping is the foundation of network monitoring. It's the first check that fails when a host becomes unreachable, and it gives you two critical metrics — latency and packet loss — that no other monitoring type provides.
- Latency tells you how fast packets travel to a host and back. Rising latency is an early warning of network problems.
- Packet loss tells you how reliable the connection is. Even small amounts degrade user experience significantly.
- Use ping for network reachability, latency baselines, router monitoring, and upstream provider checks.
- Combine with HTTP, TCP, and DNS monitoring for full-stack visibility.
- Don't rely on ping alone — it can't tell you if your application is healthy, only that the host is reachable.
The simplest question in networking — "Are you there?" — is still one of the most important.