A website will not load.
What next?

It responds here, but not for you

Our server reached the website. Your browser may be taking a different route, using different DNS, or loading a different page. First verify the exact address you need; a homepage response says nothing about a checkout or login.

1. Try a private browser window. If it works, examine extensions and site-specific stored data rather than clearing every account’s data.
2. Try another device on the same network. If both fail, compare a different network, such as mobile data. Data charges may apply.
3. Look at the service’s official status page for the affected feature or region.
4. If only your office network fails, ask its administrator to investigate filtering, proxy or DNS configuration.

A difference between networks is a clue, not proof of an ISP outage. Do not disable security protections or bypass certificate warnings.

No address found, or DNS lookup failed

“Address not found” means the DNS lookup did not return A or AAAA addresses. Confirm the spelling, including the subdomain. A recently changed domain may have inconsistent DNS answers while changes propagate. We retry selected failures within the same server perspective; two attempts do not establish a global failure.

“Our DNS lookup failed” is different: the resolver could not complete the lookup. It does not mean the domain does not exist. Try again later or compare an independent resolver.

If you own the website, verify registration, authoritative nameservers and the intended A, AAAA or CNAME records. Record the time and resolver used before changing anything. An email-only hostname may legitimately have no website address.

The check was blocked

HTTP 401, 403, 407, 429 and 451 indicate restricted access in this tool. Websites can require authentication, challenge automated clients, limit traffic or apply regional restrictions. This response proves the server answered; it does not prove the page works for an ordinary visitor.

Open the website directly in your browser and follow its normal login or verification process. For HTTP 429, stop retrying repeatedly and respect the server’s retry instructions. Do not use the checker to evade a block. If you own the site, compare firewall logs for the timestamp and hostname rather than disabling protection broadly.

The server returned an HTTP error

404: the requested page was not found. Check the path and try the homepage. 410: the resource may have been intentionally removed. These are page-level responses, not proof of a site-wide outage.

500: the application reported a server error. 502 or 504: a gateway had trouble with an upstream response. 503: the service reported that it is unavailable, sometimes during maintenance or overload. We make one bounded retry for 5xx errors and show both observations.

If you operate the website, correlate the response time with deployment, application, gateway and infrastructure logs. Test the affected route without sensitive query parameters. If you are a visitor, check the official incident page and try again later.

Timeout, TLS or another connection problem

An inconclusive check can result from a slow server, filtering, DNS service failure or a connection error. Our entire upstream check has an eight-second budget, shared by up to two attempts. We cannot reliably distinguish a certificate problem from every other network error through the HTTP checker.

An HTTPS response confirms that an HTTPS connection completed for that request. It is not a certificate-expiry scan, security audit or guarantee that every subdomain is configured correctly. If your browser displays a certificate warning, stop and contact the operator; do not ignore the warning to force access.

For your own website, check the certificate’s hostname coverage, expiry and certificate chain using your hosting provider’s tools. Compare origin health with proxy or CDN health.

Too many redirects

We follow up to five redirects per attempt and show the path. A longer chain can be legitimate, but repeated URLs or HTTP-to-HTTPS-to-HTTP changes can reveal a configuration loop.

If you own the site, compare redirect rules at the application, web server and CDN. Confirm the intended canonical hostname and scheme. Change one rule at a time and test in a clean browser session. A browser’s cached redirect may differ from our current observation.