Is a 4xx status code proof that the site is up?

It proves the request reached a responding HTTP layer. The site may still be unusable for the intended user, but it is not the same as a DNS, connection, or TLS failure.

Is 503 worse than 403?

They mean different things. A 503 usually suggests overload or temporary unavailability, while 403 usually means access was denied by policy or application logic.

Why should I care about 301 and 302 in diagnostics?

Because redirects change the destination that actually serves the user. A perfectly normal redirect can lead to a broken final host, certificate, or application path.

HTTP interpretation

What HTTP status codes mean in diagnostics

Understand how HTTP status codes should be interpreted in website diagnostics, including redirects, client errors, server errors, and the difference between a real response and a lower-layer failure.

HTTP status codes are useful, but they are easy to misuse. A 503 is not the same kind of problem as a timeout. A 403 proves the server answered even if the page is unusable. A 301 can quietly send users from a healthy URL to a broken destination. In diagnostics, the right question is not “which code is bad?” but “what stage of the request path did we actually reach before the problem showed itself?”

A status code means something answered

If you have a real HTTP code, the request reached a layer that could return an HTTP response. That already rules out some lower-layer failures.

Redirects deserve as much attention as errors

A 301 or 302 can move a user from a healthy URL to an unhealthy final destination, so the chain matters as much as the final code.

No status code can be the most important clue

If the request failed in DNS, connection, or TLS, the absence of an HTTP code tells you more than any server response could.

How status codes fit into diagnostics

Think of status codes as application-layer evidence, not as a complete health verdict on their own.

2xx means the request completed successfully

It usually proves the URL responded normally from this server, but it does not guarantee the content was the exact experience every user expected.

3xx means the request is moving somewhere else

In diagnostics, redirects are meaningful because the destination can change trust, performance, or availability characteristics.

4xx means the server understood the request but rejected or limited it

This is still a real response. It often points to access policy, path issues, rate limiting, or authentication requirements rather than a dead site.

5xx means the server path is alive enough to fail visibly

The request reached an application, gateway, or upstream dependency, but the response was not healthy.

Common status codes and how to read them

These are the codes most likely to matter on a public diagnostics page.

Code	Typical meaning	Diagnostic takeaway
200	The request succeeded	The URL worked from this server. If users still complain, compare region, browser, auth, or client-side behavior.
301 / 308	Permanent redirect	Check the final destination carefully. The starting URL may be fine while the destination is broken.
302 / 307	Temporary redirect	Useful when behavior changes between environments or campaigns because the redirect target may be conditional.
401	Authentication required	The server is alive, but the request was not authorized. This is not a raw outage.
403	Forbidden	The request reached a policy or application rule and was denied. Often caused by WAF, permission, or IP-based restrictions.
404	Not found	The host and application answered, but the path was missing or routed incorrectly.
429	Too many requests	The site is alive but rate limiting is in effect. Public diagnostics can trigger this on some providers.
500	Internal server error	The application failed after receiving the request.
502	Bad gateway	A proxy or edge did not receive a good answer from the upstream service.
503	Service unavailable	The app or edge is overloaded, in maintenance, or intentionally unavailable.
504	Gateway timeout	An upstream dependency was too slow or absent, so the gateway timed out.

When the status code is not the root issue

Sometimes the code is real but still not the most important layer to investigate.

Redirects can hide the actual failure point

A 301 from the original URL may look harmless until the final HTTPS destination fails on certificate trust or a different host.

A 403 can be caused by edge policy, not the application itself

Geo rules, IP reputation, WAF policy, or bot filtering can produce a healthy-looking server response that still blocks users.

A 5xx may still have DNS, SSL, or platform context around it

If the route involves multiple hostnames or provider edges, the surrounding DNS and TLS data can still explain why the failure surfaced there.

Best follow-up checks after an HTTP status code

Pick the next page by the kind of code you saw and the uncertainty you still have.

URL diagnosticsStay on Website Checker for redirect and timing context

Best when you need to see the chain, final URL, headers, and phase timings around the code that appeared.

Website Checker Certificate and TLS inspectionUse SSL Checker after suspicious HTTPS redirects

Helpful when a redirect lands on a host that may have certificate, hostname, or TLS issues.

SSL Checker Provider and edge hintsUse Hosting Checker when a 5xx looks platform-related

Useful if the headers and hostnames suggest CDN, managed platform, or provider-edge behavior behind the error.

Hosting Checker Parsed DNS answersUse DNS Lookup when hostname changes are part of the story

Open it if redirects or environment differences suggest traffic may be reaching different infrastructure than expected.

DNS Lookup

Common mistakes when reading status codes

These shortcuts flatten useful nuance out of diagnostics.

Calling a 403 or 404 “downtime” without acknowledging that the server still answered.
Ignoring the redirect chain and focusing only on the final status code.
Treating 429 as proof the site is broken instead of recognizing rate limiting.
Forgetting that no HTTP code at all may be the strongest clue that the failure happened below the application layer.