Pick up to three targets and press Start. One request a second uses about 3 MB an hour. The load test uses up to about 450 MB.
| Target | Sent | Lost | Loss | Last | Min | Median | 95th | Max | Jitter |
|---|---|---|---|---|---|---|---|---|---|
| No samples yet. | |||||||||
| Cloudflare's view of your connection | TCP round trip (median) | Packets resent | Packets lost |
|---|
What it says so far
- WaitingRun it for at least a minute, ideally while the problem is happening.
Packet loss and jitter, explained
live demoEvery block is one request travelling from you to a server. The tool above sends one a second and times each one. This is what the three results look like.
How do I run a packet loss test?
Press Start and leave this page open while the problem is happening, ideally for ten minutes or more. The Loss column shows how many requests never came back from each target. On a healthy wired connection it should be 0%. Around 1% is enough to make video calls and games stutter.
What is jitter, and how much is too much?
Jitter is how much the delay changes from one request to the next. Calls and games cope well with steady delay, and badly with delay that jumps about. Cisco's guidance for voice is jitter under 30 ms, one-way delay under 150 ms and loss under 1%.
What is a good latency?
To a server in your own country, fibre and cable broadband usually come in under 30 ms. Mobile and satellite connections are higher. The bigger warning sign is delay that climbs when the line is busy, which the load test shows.
How do I check for packet loss from the command line?
On Windows, run ping -n 100 8.8.8.8 and read the Lost figure at the end, or pathping -n 8.8.8.8 to see where it starts. On macOS and Linux, ping -c 100 8.8.8.8 gives a packet loss percentage and mtr -rwnzc 100 8.8.8.8 shows it hop by hop.
How do I fix packet loss?
Work from your end outwards. Test on a cable: if the loss goes away, it's the Wi-Fi. Restart the router and check the cable into it. If the line only falls apart when it's busy, turn on smart queue management (SQM) on the router. If every target shows loss on a cable, export the CSV and send it to your ISP.
Is this the same as a ping test?
Close, but not quite. A web page can't send a ping, so each sample is a tiny HTTPS request that costs about one round trip. Compare the targets with each other and over time rather than with a ping from another tool. The section below explains the difference.
Reading the result
| What you see | What it usually means | What to try |
|---|---|---|
| Spikes and lost requests on every target at the same moments | The problem is between you and your ISP: Wi-Fi, your router, the line, or the ISP's access network. | Run it again on a cable. If it is clean on a cable, it is the Wi-Fi. If not, restart the router, then send the CSV to your ISP. |
| Only one target is bad | That provider, or the path to it. Your connection is fine. | Nothing to fix at your end. Test the service from somewhere else to confirm. |
| Delay jumps when the line is busy (the load test) | Buffers in the router or modem filling up, often called bufferbloat. Calls and games stutter whenever someone uploads or streams. | Turn on smart queue management (SQM, fq_codel or CAKE) on the router, or shape the line to just under its real speed. |
| Delay varies a lot, loss comes in bursts | Usually Wi-Fi: distance, walls or a crowded channel. | Move closer, use 5 GHz, change channel, or run a cable to the devices that matter. |
| Cloudflare reports packets resent, but no requests failed | Packets are being lost and TCP is quietly sending them again. Applications feel slow rather than broken. | Treat it as loss: same checks as above. |
What it measures, and what it cannot
A request, not a ping
A web page cannot send ICMP. Each sample is a tiny HTTPS request on a connection that is already open, so it costs about one network round trip plus a few milliseconds at the far end. Compare targets with each other and over time, rather than with a ping from another tool.
Cloudflare's own figures
Cloudflare reports how its server sees your TCP connection: the round trip it measured and how many packets it had to send again. That is the nearest a web page gets to real packet loss.
No hop-by-hop view
It tells you whether and when, not which router. For the hops, run pathping -n 8.8.8.8 on Windows or mtr -rwnzc 300 8.8.8.8 on macOS and Linux while this is running.
The middle-hop trap
Loss at one hop in a traceroute that does not carry on to the later hops is that router choosing not to answer you, not lost traffic. Real loss continues all the way to the last hop.
Leave the tab open
It keeps measuring in a background tab, but not if the computer sleeps. Gaps are shaded on the chart so you can tell missing data from good data.
On a Cisco router
ping 8.8.8.8 repeat 1000 size 1400 source Gi0/0/0 gives you the same answer from the edge of your network. For a standing record, configure IP SLA with an icmp-echo probe. The WAN failover flow has the commands.