--- title: Free Ping description: ICMP echo request — round-trip time, jitter, packet loss. canonical: https://watchfor.io/ping-test --- [Back to all free tools](/free-tools) # Ping ICMP echo request — round-trip time, jitter, packet loss. [How to use this tool](/blog/how-to-ping-a-server-online) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is Ping ? Ping is the most basic reachability check on the internet: send an ICMP echo request, see if you get an echo reply back, measure how long it took. When something "can't be reached" — a server, a printer, a customer's site — ping is the first question. Is it network-level down, or is the higher layer broken? This tool runs the standard ICMP ping sequence against any public IP or hostname and gives you the four numbers everyone wants: round-trip time (min/avg/max), jitter, packet loss percentage, and whether the host actually replied. It runs from a real server with real network egress, not from your browser (browsers can't send raw ICMP — pings that "run in your browser" are usually HTTP requests in disguise). ## How it works Each ping run is a small sequence of ICMP packets: - 1 Resolve hostname if needed — If you typed a hostname, we do a quick DNS lookup first to find the target IP. If you typed an IP, we skip resolution. - 2 Send N ICMP Echo Request packets — Default 5 packets, configurable up to 20. Spaced 200ms apart (to avoid hammering the target). Each packet is 56 bytes of payload + 8 bytes ICMP header + 20 bytes IP header — 84 bytes on the wire. - 3 Wait up to 1s per packet for reply — Each ICMP Echo Request includes a unique sequence number. The target's kernel auto-replies with an ICMP Echo Reply carrying the same sequence number. We match replies to requests by sequence and record the round-trip time. The whole run has a time budget that grows with the number of pings; on a very slow or lossy path it can end before every ping is sent, and the result then shows fewer packets sent. - 4 Aggregate and report — Min/max/avg RTT across replies received. Jitter = standard deviation of RTT. Packet loss % = (sent - received) / sent. You also see how many packets were sent and received, and a bar per packet with its RTT or "lost". If no reply came back at all, the result says the host is unreachable and shows 100% loss. ## When you'd use it ### "Is the server down or is my app broken?" App returns 500 errors. Ping the server. If ping succeeds with normal latency, the host is up and routable — your app is the problem. If ping fails, the host is unreachable from this part of the internet — escalate to ops, check the cloud provider's status page. ### Latency baseline before a deploy Before moving an origin from one region to another, ping the current and target and compare the RTTs. Free runs use the probe location nearest you; plans with location choice can repeat the run from other regions. If the new origin is 80ms further from your user base, expect a noticeable real-world latency increase even if everything else is identical. ### Verify route convergence after a network change ISP changed BGP routing overnight. Ping a host known to be on the affected path. Steady low latency = converged. Sporadic timeouts and high jitter = routing is still flapping; wait or escalate. ### Customer complaint triage Customer says "the site is slow." Ping from our prober — sub-100ms = the issue isn't network latency at the IP level, it's higher up (TLS handshake, application response, DNS). High latency or loss = real network issue, you can hand off to network ops with evidence. ### Spot intermittent connectivity 20-packet ping reveals patterns a 5-packet ping hides. 19/20 success at 30ms with one timed-out packet = single dropped packet (normal). 12/20 with random timeouts and RTT all over the map = something on the path is unhealthy (congested link, route flapping). ## Reading the result ### RTT min / max / avg Round-trip time in milliseconds. Min = fastest single packet (closest to the true network path latency). Avg = mean across all received packets. Max = slowest, useful for spotting tail latency. A min of 20ms and max of 800ms means the path is mostly fast but has occasional slow packets — congestion or buffer queueing somewhere. ### Jitter Standard deviation of RTT. Low jitter (a few ms) = stable path, packets all take the same time. High jitter (>30ms on a path with avg <100ms) = real-time-sensitive apps (VoIP, video calls) will sound choppy. Routes through congested ISP links or saturated wifi often show high jitter. ### Packet loss Percentage of pings that got no reply. 0% on a healthy path. 1-5% is sometimes acceptable on poor wireless links. >10% means the path is broken — TCP will retransmit constantly, the user sees latency spikes and timeouts. 100% means either total unreachability or the target is configured to drop ICMP. ### Why a host might reply slowly even when "up" ICMP is often deprioritised at routers — they handle real traffic first, ping responses second. So ping RTT can be higher than the actual TCP/UDP path latency. Don't use ping alone for SLA reporting; use ping for binary up/down, use TCP-level checks for latency that matches user experience. ## Common pitfalls ### "Host says it's up but ping shows 100% loss" Many firewalls and cloud providers drop ICMP by default. AWS EC2 doesn't allow ICMP inbound unless your security group explicitly permits it. Same for Cloudflare proxied origins (their edge serves HTTP, blocks ICMP to origin). Ping failure ≠ host down — verify with a TCP port check on a known-listening port (80, 443, 22). ### Ping works from your laptop but fails from the tool Different paths. Your laptop sees the path from your ISP; we see it from our prober's ISP. Different paths can have different ACLs, different congestion, different routing decisions. If your plan lets you pick the location, run it from another region to see whether it's a single bad path or genuinely broken. ### Latency way higher than expected Could be (1) wrong region — geographically distant prober, (2) route is going through unexpected hops — use traceroute to see, (3) target is queueing ICMP responses behind real traffic. Compare against a TCP connect() time to the same host on a real port — that's usually closer to actual application latency. ### Inconsistent results between runs Internet paths flap. A 5-packet ping is too small a sample for an unstable path. Use 20 packets if you need to characterize stability. Or just accept that ping is a snapshot, not a measurement — for production latency tracking, use continuous monitoring. ## Run Ping on every change, not just once. Get alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions Why does my host respond to ping in the browser but not in this tool? Browsers can't send ICMP — what looks like "ping" in a browser is almost always an HTTP HEAD request, which uses TCP port 80/443 and bypasses any ICMP-level firewall. We send real ICMP. If browser "ping" works and ours doesn't, the target blocks ICMP but allows HTTP. Is ping a reliable measurement of network speed? No. Ping measures the round-trip time of small ICMP packets along the network path. Real "speed" depends on bandwidth (how much data you can push per second), application latency (TLS handshake, server processing), and bufferbloat (which ping won't show under no load). Use ping for reachability + path latency, not throughput. What's a good ping latency? Depends on geographic distance. Same-city ping is typically <10ms. Same-continent is 20-80ms. Trans-continental is 100-200ms. Around the world is 250-350ms (limited by the speed of light over fiber). Anything dramatically higher than the great-circle distance ÷ 200,000 km/s suggests an inefficient route or congestion. Can I ping a website? You can ping the IP that website resolves to. Many big sites (Cloudflare-proxied, AWS-fronted) deliberately don't respond to ICMP at the IP level. Failure to ping doesn't mean the website is down — try fetching the homepage with the HTTP Headers tool instead. Why does the ping show some packets out of order? Packets in IP networks aren't guaranteed to arrive in send order. Different packets can take different paths (ECMP routing), or a router queue can reorder them. Modern OS ping output usually re-sorts by sequence number for display, but the underlying data is fine. Can I ping IPv6 addresses? Not in this tool: it pings over IPv4 only, so a hostname is resolved to its IPv4 address. The protocol equivalent is ICMPv6 Echo Request, and Ping monitors can already run over IPv6. My ping says 100% loss but the website works fine — should I be worried? No, just informative. The target is reachable on whatever port the website serves (usually 443) but blocks ICMP. This is a deliberate configuration choice by the host/CDN. The website is up; ICMP is just not the right tool to verify it. What's jitter and why does it matter? Jitter is the variation in round-trip time across packets. Low jitter = a stable path. High jitter = packets take inconsistent times, usually because of congestion, queueing, or route flapping. It's important for real-time apps (voice/video) where you need consistent delivery timing. ## Related network tools - [TracerouteTrace the network path hop by hop, with packet loss and average latency at each hop (MTR-style).](/traceroute-online) - [Port CheckerTest TCP port reachability and optionally grab the server banner.](/port-checker) - [Blacklist CheckCheck an IPv4 address against the Spamhaus ZEN, SpamCop and Barracuda blocklists (a domain is checked through the address it resolves to).](/blacklist-checker) - [What Is My IPSee your public IPv4 / IPv6 address, approximate location (city, region, country), timezone and map coordinates — detected instantly from your connection, no signup.](/whats-my-ip) --- Canonical page: https://watchfor.io/ping-test · Site guide: https://watchfor.io/llms.txt