Unanswered probes
The share of requests that received no reply before the timeout. This is the closest a browser can get to packet loss — see the limitation below, which matters.
A one-second check tells you the connection worked for one second. Dropouts, loss and instability are by nature occasional, so this test runs for up to a minute and reports what happened across the whole window.
The share of requests that received no reply before the timeout. This is the closest a browser can get to packet loss — see the limitation below, which matters.
How much the round-trip time varied. Steady is good: voice and video can absorb a consistent delay far better than an inconsistent one.
Moments where nothing answered for more than two seconds. A single one during a call is audible; several suggest something is genuinely dropping out.
Fifteen seconds catches a bad connection. Sixty is better for an intermittent one — the whole point is to be running when the problem happens.
This matters enough to say plainly: a browser cannot see packet loss. It has no access to ICMP and no view of individual IP packets. What it can see is HTTPS requests that did not come back within a timeout.
Those two things overlap but are not the same. A request can fail because a packet was dropped, and also because the far end was rate limiting, because a middlebox interfered, or because the connection was briefly busy with something else. That is why this tool reports unanswered probes rather than claiming a packet-loss percentage, and why the finding is marked as likely rather than measured.
Treat a non-zero result as a strong signal worth confirming with the right instrument: a sustained ping or an mtr run from the machine itself, which does see the IP layer. If that comes back clean, the problem was somewhere above it.
Tools that print a confident packet-loss figure from a browser are reporting the same measurement with a more impressive label on it.
For voice and video, under 1% is generally fine and modern codecs conceal it. Between 1% and 2.5% is audible as occasional clipping. Above 5% calls become difficult and file transfers slow dramatically, because TCP interprets loss as congestion and backs off.
Because that is what it measured. A browser cannot send ICMP or observe individual packets; it can only notice that an HTTPS request did not complete. Calling that packet loss would be claiming more precision than the instrument has. The distinction is not pedantry — it changes what you should check next.
Probably the ping, for the loss figure specifically. That combination usually means requests were being refused or delayed at the application layer rather than packets being dropped on the path. It is still worth investigating, but it is a different problem with different causes.
On Wi-Fi, by far the most common cause is interference or a marginal signal — try Ethernet first, as it eliminates the largest variable in one step. On wired connections, look at cabling and connectors, then at the time of day: a pattern that appears every evening points at upstream congestion rather than anything in the building.
If you are chasing something intermittent, yes. A short test that comes back clean has not proved much about a problem that happens every few minutes. If you are checking a connection that is obviously bad right now, 15 seconds is enough.