When a website refuses to load, the first useful question is simple: is the site actually down, or is the problem somewhere between you and the site? A status check gives you an independent view of the public endpoint so you can start troubleshooting with…

When a website refuses to load, the first useful question is simple: is the site actually down, or is the problem somewhere between you and the site? A status check gives you an independent view of the public endpoint so you can start troubleshooting with evidence instead of guesswork.

What WebLens checks

The WebLens Website Status tool sends a request to the target and reports whether it can be reached successfully. It records the HTTP status code, the host, and the time taken for the request. For this tool, a response in the 200–399 range is treated as online; a 4xx or 5xx response is treated as offline for the dedicated status result. A request failure is also reported as offline.

That distinction matters. “Online” here means the WebLens server received a successful HTTP response. It does not mean every page, API route, asset, login flow, or visitor can use the website normally.

How to run a useful check

  1. Enter the relevant domain, URL or IP.
  2. Run the status check and note the HTTP status and response time together.
  3. If the result is offline, run the WebLens HTTP Status Checker to inspect the returned status more directly.
  4. If the site responds but behaves strangely, compare the result with DNS, SSL, and header diagnostics before changing server settings.

How to read the result

A 2xx response normally indicates that the request succeeded. A 3xx response is a redirect, so the site can still be reachable while the requested URL points elsewhere. A 4xx response means the server returned a client-side error such as “not found” or “forbidden.” A 5xx response indicates a server-side error. The status code is a clue about the failure mode, not a complete diagnosis.

Response time is contextual. A 150 ms result from one checking location does not guarantee the same experience for a visitor on another network. DNS resolution, routing, a CDN, TLS negotiation, server load, and geography can all affect timing.

A practical troubleshooting example

Suppose your team reports that example.com is unavailable. WebLens returns “Website online,” HTTP 200, and a normal response time. That evidence suggests the public homepage is responding from the WebLens environment. Your next checks should focus on the affected user’s network, DNS resolution, browser cache, authentication, or a route that differs from the homepage.

Now imagine the result is HTTP 503. That gives you a different starting point. Check the origin server, reverse proxy, load balancer, application health, deployment status, and upstream dependencies. If the result is a connection failure, investigate DNS, firewall rules, TLS, routing, and whether the service is listening.

Why two people can see different results

Websites are rarely a single server. A domain may use multiple DNS answers, a CDN, regional routing, WAF rules, load balancing, or different application paths. A diagnostic run is a point-in-time observation from WebLens infrastructure. It cannot establish that every visitor is seeing the same response.

What this check cannot prove

The status tool does not provide historical uptime, transaction monitoring, browser rendering, JavaScript health, database health, or application-level correctness. A site can return HTTP 200 while a checkout flow is broken. Conversely, a temporary edge error may affect one path while the origin remains healthy.

Use the result as the first piece of evidence

For an incident, start with external status, then move inward: HTTP status, DNS, SSL, headers, and finally server or application logs. That sequence helps narrow the problem without changing multiple systems at once.

Ready to check a site? Open the WebLens Website Status Checker, enter the public URL, and use the returned status and timing as your first diagnostic snapshot.

What to check when the result surprises you

If WebLens says a site is online but a customer still sees an error, test the exact failing URL rather than only the homepage. A homepage can return 200 while an API, login route, checkout path, or static asset returns 4xx or 5xx. Compare the hostname and scheme too: www.example.com and example.com can be separate endpoints even when a redirect connects them.

If WebLens says the site is offline, avoid changing DNS immediately. First determine whether the failure is a connection problem or an HTTP response. A returned 503 is evidence that an HTTP server or gateway answered; a request failure points toward an earlier layer. This distinction can prevent an unnecessary DNS change during an application incident.

A compact incident checklist

Record the check time, hostname, HTTP status, and response time. Run the status check again after a short interval if the incident is intermittent. Then compare DNS, SSL, and HTTP headers. If all public checks look healthy, investigate the affected network, authentication path, browser behavior, or application-specific route. If the same failure repeats from WebLens, move the investigation toward the public infrastructure and server logs.