LumaProbe sends a HEAD request from its server. Private and reserved destinations, credentials and non-standard ports are blocked. The result describes the response from this server, not every visitor worldwide.
A 200-series code usually means success, 300-series means a redirect, 400-series a request or access issue, and 500-series a server problem. Some sites deliberately reject automated HEAD requests.
The server validates the supplied public HTTP or HTTPS URL, resolves its host and rejects private, reserved, credential-bearing and non-standard-port destinations. It then sends one HEAD request with a six-second timeout, verifies TLS for HTTPS and does not follow redirects.
The result includes the status code, response time and a redirect location if returned. A HEAD request asks for headers rather than the full page; some otherwise working sites block or mishandle HEAD, so one failed result is not final proof that the service is down.
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.
A 2xx response generally means the endpoint answered successfully. A 3xx response redirects elsewhere. A 4xx response can indicate a missing page, authentication requirement or blocked request, while 5xx usually indicates a server-side problem. The exact meaning depends on the site and requested path.
LumaProbe checks from its server, not from your home connection and not from multiple global regions. If it receives a response while your device does not, investigate local DNS, filtering, VPN, browser state or routing. If official status and several independent networks also fail, a wider problem becomes more plausible.
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.
Check the URL and try the service’s homepage. Consult the official status or support page, then compare another device and another connection such as mobile data. Do not repeatedly probe sites you do not operate or have permission to test.
For your own site, inspect server logs, DNS, certificate validity and monitoring from more than one region. Use a full browser visit or an authorised monitoring service when the application depends on JavaScript or rejects HEAD requests.
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.