Where to start
Start with the exact page URL. Compare your browser with a check from NetLuma, then try a second network. Read the HTTP result before deciding what to investigate. One successful or failed request cannot establish a worldwide outage.
Open Website status1. Check the exact address that fails
Copy the address from your browser, including its path. If example.com opens but example.com/account does not, those are different observations. A page may have moved or require sign-in while the homepage remains available.
Check the spelling and whether the address uses www, another subdomain or a different scheme. NetLuma assumes HTTPS when you enter a bare domain. Use the full HTTP URL if you specifically want to test that starting point.
Check the exact website URL2. Compare your browser with another connection
Run Website status for the same URL. The request comes from the server hosting NetLuma, giving you a second point of observation. Record the result and time while the browser problem is still happening.
If possible, try your own device on another network, such as mobile data instead of Wi-Fi. Change one thing at a time so you can tell which comparison matters. A VPN or proxy can affect the route and the address a website sees.
3. Use the response to choose the next check
An HTTP response means the request reached a server that answered. The code helps distinguish a successful response, an access rule, a missing page and an application error. It does not tell you whether every feature on the page works.
| Observed result | Useful next step |
|---|---|
| 200–299 | Compare the browser and another network. Check whether the failure involves a script or a particular feature. |
| 401 or 403 | Check whether sign-in, permission rules or automated-request restrictions explain the response. |
| 404 | Compare the exact path with the homepage and look for a moved or mistyped page. |
| 429 | Allow the request limit to recover rather than repeatedly submitting checks. |
| 500–599 | If you own the site, review hosting status and application logs for the affected request. |
| No completed response | Inspect DNS and HTTPS, then compare from another network. |
On a small screen, scroll the table sideways to see both columns.
4. If NetLuma responds but your browser fails
Try the same address in a private browser window. This can help separate a stored session or browser extension from the public page. If the page opens there, investigate the relevant browser setting before clearing unrelated data.
A successful server check still cannot test an interactive login, client-side application or every resource on the page. If only a feature fails, note the action that triggers it and the message shown. That is more useful to the site owner than a general report that the whole site is down.
5. Check DNS, HTTPS and the final destination
Use DNS lookup for the exact hostname when the connection cannot start or a domain was recently changed. Compare the records with the expected hosting configuration. NetLuma uses one DNS resolver, so a different network can still have a different cached answer.
Use SSL checker when the browser reports a certificate problem. If the address moves through redirects, use Redirect checker to inspect the final hostname and page. A working original domain can lead to a failing destination.
Trace the redirect path6. Turn the comparison into a useful report
Write down the exact public URL, approximate time, browser message, NetLuma HTTP result and whether another network behaved differently. For your own website, compare that time with hosting events and application errors.
For a website you do not own, check its official status or support channel if it has one. NetLuma performs a one-time check from one hosting server. It does not run a global outage survey or calculate historical uptime. Its response time is time to first byte, not your internet bandwidth or a full page load measurement.
Technical references
Provider documentation and technical explanations supporting this guide.