How to Read Ping Test Results: Min, Max, Average and Jitter Explained
A Ping Test Result Is Four Numbers, Not One
Most people run a ping test, glance at a single figure, and close the tab. But a good test sends many packets and reports the minimum, maximum, and average round-trip time plus jitter — and the relationship between those numbers tells you far more than any one of them alone. Two connections can share a 35ms average while one is rock solid and the other is falling apart. Here's how to read the whole report.
The quickest way to think about it: the minimum tells you what your route is physically capable of, the average tells you what you typically get, the maximum tells you how bad the worst moment was, and jitter tells you how often things move around. Diagnosing a connection means asking which of those four is out of line, because each one points at a different cause and a different fix.
Minimum: The Best Your Route Can Do
The minimum is the fastest round trip recorded during the test — the closest thing to the physical floor of your route. It's dominated by distance and infrastructure: light in fiber covers roughly 200 km per millisecond one-way — and a round trip covers that distance twice — so a server 1,500 km away can never answer in 5ms. If your minimum is already high, no router tweak will fix it; the only levers are choosing a closer server or a better route. Treat the minimum as your connection's potential.
Three things set that floor, and only one of them is under your control:
- Distance and routing. Traffic rarely takes a straight line. A poorly routed path can send your packets hundreds of kilometres past their destination and back, adding latency that no local change will recover. A traceroute is the tool that exposes this.
- Access technology. Fiber and cable add very little on top of distance. DSL adds a few milliseconds of interleaving, 4G and 5G add radio scheduling delay, and geostationary satellite adds hundreds of milliseconds that no amount of bandwidth will remove.
- Your own equipment. A congested or underpowered router adds a small but real floor of its own. This is the one part you can actually replace.
A minimum that is close to what geography predicts means the path itself is healthy. Everything above that minimum — the average, the maximum, the jitter — is delay that got added somewhere along the way, and that is where the fixable problems live.
Average: The Headline Number (and Its Blind Spot)
The average is what people quote, and it's a fair summary when the connection is stable. Its blind spot is that it hides variation: a test that returns 20, 21, 20, 95, 22ms averages around 36ms, which looks fine — yet that single 95ms outlier is exactly the kind of hiccup that drops a frame or clips a word. Never judge a connection by the average alone; always check it against the minimum and maximum.
The useful trick is to compare the average against the minimum. If the average sits within a few milliseconds of the minimum, almost every packet is taking the fast path and your connection is doing well. If the average is meaningfully higher than the minimum, something is regularly adding delay: a busy Wi-Fi channel, a queue building up in your router, or congestion further upstream. The size of that gap is a better health indicator than the average itself.
Maximum and the Min-Max Spread
The maximum is the worst round trip in the sample, and the gap between minimum and maximum is the most underrated diagnostic in the report:
| Min-max spread | Verdict | Usual cause |
|---|---|---|
| Under ~10ms | Excellent | Nothing to fix. Your route is consistent and whatever the average says is trustworthy. |
| 10-30ms | Normal | Typical for Wi-Fi or busy hours. Usually harmless, worth watching if it grows. |
| 30-50ms | Worth investigating | Background traffic, wireless retransmissions, or early-stage queueing on a loaded line. |
| Over ~50ms | A real problem | Something is queueing or interfering — saturated upload, bufferbloat, or congestion. The average is now hiding real problems. |
A 25ms average with a 24-90ms range is a worse connection than a 45ms average with a 43-49ms range, even though the first "wins" on the headline number. Real-time apps live at the bad end of the range: every packet that arrives late is a moment the game or call has to paper over, no matter how flattering the average looks.
One caveat on the maximum specifically: it is a single sample, so it is the least statistically robust number in the report. One 400ms outlier in a 30-sample test could be a genuine problem or could be your operating system deciding to check for updates mid-run. That is why the maximum should always be read next to jitter, which is calculated from every sample rather than just the worst one, and why repeated spikes deserve their own dedicated troubleshooting rather than a shrug.
Jitter: The Spread, Summarized
Jitter condenses that variation into one figure: how much the round-trip time changes between consecutive measurements. Under 5ms is excellent, under 10ms is good, and anything over 20ms will be felt in real-time apps regardless of your average ping. Jitter is the stability score of your connection — our jitter vs ping guide goes deeper on why variance often hurts more than stable delay.
Because jitter averages across the whole sample, it answers a different question than the maximum does. A high maximum with low jitter means one bad moment in an otherwise steady run. A high maximum with high jitter means the connection is unsettled throughout, and the maximum simply happened to be the worst instance of a pattern. The first is often ignorable; the second rarely is.
Reading All Four Together
The interesting part is not any single number but the shape they make. These four patterns cover most results you will ever see:
| Min / Avg / Max / Jitter | What it means | Where to look |
|---|---|---|
| 18 / 20 / 26 / 2ms | Healthy connection, close server, nothing queueing | Nothing. This is what a good result looks like. |
| 18 / 22 / 140 / 4ms | Fundamentally stable with one isolated spike | Re-run the test. If the spike does not repeat, ignore it. |
| 18 / 55 / 95 / 24ms | Good floor, but delay is being added constantly | Wi-Fi, background traffic, or a router queue. Test again on Ethernet with everything paused. |
| 85 / 88 / 93 / 3ms | Very stable, but the route itself is long | Geography or routing. Pick a closer region; local fixes will not help. |
Notice that the third and fourth rows would look similar if you only read the average, yet they need completely opposite responses. That is the whole argument for reading the full report.
Where Packet Loss Fits In
Loss is not one of the four latency numbers, but it overrides all of them. If a test reports packets that never came back, the latency figures only describe the packets that survived — and a real-time application cannot simply retry a lost packet without it arriving too late to matter. Treat anything above roughly 0.5% as a result worth chasing before you spend time optimizing an average that is already fine.
Why Each Region Shows Different Numbers
A browser test like CheckPing measures HTTPS round-trip times to cloud endpoints in multiple regions — a real-world proxy for latency, not the ICMP ping command or an in-game counter. That's why the per-region breakdown matters: your nearest region reflects your connection's health, while distant regions mostly reflect geography. A high number to a continent away is physics, not a fault. Compare regions against each other and against your own past results, not against someone else's screenshot.
Two comparisons are worth making every time. First, nearest region against its own history: if your closest endpoint used to read 20ms and now reads 45ms, something changed on your side or your ISP's. Second, nearest against distant: if every region rose by a similar amount, the added delay is happening close to you, since it is affecting all routes equally. If only one region degraded, the problem is out in the routing, not in your house.
When to Retest Before Drawing Conclusions
One test is a snapshot. Before acting on a result, retest when:
- The max or jitter looks bad once: a single background process (a cloud sync burst, an update check) can poison one run. Two or three runs separate a fluke from a pattern.
- You changed something: switched to Ethernet, moved the router, enabled QoS — always compare a fresh test to your baseline.
- The time of day changed: evening results routinely differ from afternoon ones on shared networks.
- The result contradicts how things feel: if the numbers look clean but your games or calls do not, test again while the problem is actually happening rather than after it passes.
Once you can read the numbers, the next question is what counts as good for your use case — for gaming thresholds by genre, see our guide to what makes a good ping for gaming.