Browsers cannot send raw ICMP packets. LumaProbe therefore repeats small HTTPS requests and reports failures as a browser-level stability estimate. It should not be described as a carrier-grade packet-loss measurement.
Run several tests at different times for a representative result.
Zero failed requests is expected on a healthy short test. Any failure is worth repeating over Ethernet. Persistent failures across devices should be recorded before contacting the provider.
A normal web page cannot send arbitrary raw network packets. LumaProbe therefore counts how many of eight HTTPS latency requests fail to complete successfully. The display is a browser-level stability indicator; it is not a percentage from an ICMP, TCP or UDP packet-loss instrument.
A failed request may reflect Wi-Fi interruption, routing trouble, congestion, browser cancellation, security software or a transient test-server problem. Repeat testing and an Ethernet comparison are essential before assigning the cause.
Use one device and one browser for comparisons. Pause cloud backups, game downloads, streaming and large file transfers, then note whether the device is connected by Wi-Fi, Ethernet, mobile data or a VPN. Run the check at least three times instead of choosing a single unusually good or bad result.
Change only one condition at a time. For a Wi-Fi problem, compare beside the router with the affected room. For a suspected broadband fault, add an Ethernet result if practical. Record the time because congestion and provider work can make the same connection behave differently during the day.
Zero failures in a short run is reassuring but cannot prove that the connection never loses packets. One failure is a reason to repeat, not a diagnosis. Repeated failures across separate runs, especially over Ethernet and across more than one destination, provide stronger evidence of instability.
Applications may hide loss by retransmitting data, which can appear as delay, buffering or sudden quality reduction rather than a clear error. Voice and games are especially sensitive because late real-time traffic may be unusable even when later packets arrive.
A browser sees the complete path from this device to LumaProbe, including the device, local network, provider route and test server. It cannot isolate the broadband line on its own. Browser scheduling, security software, VPNs, extensions and background activity can also influence a short test.
Treat the result as diagnostic evidence, not a contractual line measurement or a live provider-outage declaration. A provider can test a different network boundary and report a different valid number. The most useful conclusion usually comes from controlled comparisons and repeated observations.
Record several runs, compare Wi-Fi and Ethernet, pause heavy traffic and temporarily remove an optional VPN from the comparison. Check cables and power, restart the router once and use the provider’s official status checker. Preserve timestamps if the problem persists.
For a formal investigation, a provider or network technician may ask for a longer controlled test using dedicated tools. Describe LumaProbe’s number accurately as failed browser requests, rather than claiming it is an exact circuit packet-loss percentage.
Read the complete LumaProbe test methodology and privacy notes →
No browser test is exact. Device performance, browser limits, server distance and other network traffic affect the result. Compare repeated tests under the same conditions.
Test results are stored only in your browser when local storage is available. The public application does not create a user account or central result profile.
Repeat the test, pause other traffic and compare Wi-Fi with Ethernet. Change one condition at a time so the cause becomes clearer.
Some links may earn us a commission at no extra cost to you. Recommendations are categories, not paid rankings.
Affiliate disclosure