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.
Enter the full public HTTP or HTTPS address, including the page path if that specific page is failing. The checker does not accept credentials, private hosts or non-standard ports. Never paste a signed download link or URL containing a private token.
A server-side result is most useful when compared with a normal browser visit and the service’s official status page. You do not need to pause home downloads or move beside the router to improve this remote HEAD request; those steps are relevant only when the fault appears local to your connection.
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.
The check is made from one United Kingdom server and requests headers rather than the full application. A site can answer this request while a JavaScript feature, login flow, regional edge or downstream API remains broken. Conversely, a working site may deliberately reject automated HEAD requests.
One response is not continuous uptime monitoring and does not establish a global outage. The tool blocks private and reserved destinations and pins the resolved public address for the request, but owners should still use authorised monitoring and application logs for operational decisions.
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. It confirms one public URL answered a HEAD request from this server. JavaScript, login flows, regional edges and downstream services can still fail.
Some sites block automated requests or do not support HEAD correctly. Compare a normal browser visit and the official service status.
No. It is one on-demand observation from one server, not multi-region monitoring or an outage declaration.