1. Confirm the exact URL
Check the hostname, HTTPS scheme, path, spelling and whether the canonical site redirects to another hostname.
Check whether a public website is responding and review its HTTP status, response time, redirects, and final destination from the Netest server.
Enter a domain or full HTTP/HTTPS URL. The check follows safe redirects and uses a lightweight request.
The result is based on the public HTTP response observed by the Netest server.
A website can fail at several layers: DNS may not resolve, a TCP connection may be refused, TLS may fail, a server may time out, or an application may return an error page. This checker focuses on the public HTTP path and explains which kind of result it received.
A successful response means that an HTTP endpoint answered from the Netest server. It does not guarantee that every page, API, region, device or logged-in user is healthy.
Check the hostname, HTTPS scheme, path, spelling and whether the canonical site redirects to another hostname.
A 2xx response is successful, a 3xx response redirects, 4xx means the server rejected the request, and 5xx indicates server-side failure.
Use DNS Lookup, SSL Checker, HTTP Header Checker or Ping / Latency Checker to isolate the failing layer.
Run a local check and compare it with this server-side result. CDNs, geofencing, split DNS, VPNs and firewalls can create regional differences.
No. It is one observation from the Netest server. Confirm important incidents with monitoring from multiple regions and your own logs.
The web server may be online while the application, route, permissions, WAF or requested page has a problem. Read the HTTP status and final URL before troubleshooting.
No. Private and local destinations are blocked for safety. Use a local browser, curl, synthetic monitor or internal observability system.
Check DNS, try both the apex and www hostname, inspect SSL, compare another network, and review server, CDN, firewall and load-balancer logs.