HTTP Status Code Lookup
A practical reference for teams that need to understand what an HTTP response code means.
Free HTTP status code lookup: what every 2xx, 3xx, 4xx, and 5xx code means, and how to decide which codes a monitor should treat as healthy or as a failure.
When to reach for this tool
Reach for this when you need to understand what an HTTP response code means during setup, debugging, or an incident review. A one-off check is useful for diagnosis, but production systems need continuous monitoring once the immediate question is answered.
- 2xx is usually healthy, but a 200 can still hide an error body.
- 3xx redirects may be expected or a sign of a misroute.
- 4xx and 5xx tell you very different things about who is at fault.
The five status code classes at a glance
HTTP status codes group into five classes, and each means something different for monitoring. Knowing the class is usually enough to decide whether a check should pass or fail.
- 1xx Informational — the request was received and processing continues; rarely relevant to a monitor.
- 2xx Success — the request succeeded (200 OK, 201 Created, 204 No Content). Usually healthy, but a 200 can still wrap an error page.
- 3xx Redirection — the resource moved (301 permanent, 302/307 temporary). Expected for some URLs, a misroute for others; decide per endpoint.
- 4xx Client error — the request was wrong (400, 401, 403, 404, 429). The caller is at fault, though a sudden spike can signal a broken deploy.
- 5xx Server error — the server failed (500, 502, 503, 504). Almost always a real problem worth alerting on.
From one-off check to continuous monitor
Use the lookup to decide whether a status code should be treated as healthy, degraded, a redirect, or a failure in an HTTP check before you wire up alerting.
- Recreate the same check in Sandglass on an interval so the next change is caught without re-running the lookup.
- Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever fixes the problem.
- Track the result over time instead of treating one manual reading as the final answer.
Why a lookup is not monitoring
A status code in isolation can mislead. A 200 can wrap an error page and a 301 can be perfectly healthy, so decide what each code means for your service rather than trusting the number alone.
Use this tool well
Step 1: Run the check and read the result
Use the output to confirm the current state, and treat anything surprising as a starting point for diagnosis rather than a verdict.
Step 2: Define what healthy means
Write down which results count as healthy, degraded, or failed before you automate anything.
Step 3: Promote it to a continuous monitor
Recreate the same check in Sandglass on an interval so the next change is caught automatically.
Step 4: Route the alert to an owner
Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever will fix them.