Every time your browser, API client, or uptime monitor talks to a server, the response carries an HTTP status code. That three-digit code tells you whether the request succeeded, redirected, failed because of the client, or failed because of the server.
This guide breaks down the main status code classes, highlights the individual codes developers see most often, and explains what each class means for monitoring, error alerts, and API design.
HTTP status code classes at a glance
A useful mental rule: 2xx means the request worked, 4xx means the request was wrong, and 5xx means the server broke.
| Class | Meaning | Plain English | Monitoring signal |
|---|---|---|---|
| 1xx | Informational | Request received, continuing process. | Logs and low-level traces |
| 2xx | Success | The request was received, understood, and processed. | Healthy traffic |
| 3xx | Redirection | Further action is needed to complete the request. | Expected redirects or redirect issues |
| 4xx | Client error | The request is malformed, unauthorised, or cannot be fulfilled. | Client bugs, broken links, auth issues |
| 5xx | Server error | The server failed to fulfil a valid request. | Incidents, downtime, SLO burn |
Informational
1xx codes are relatively rare in everyday application development, but they can appear in advanced, streaming, or protocol-upgrade scenarios.
The server received the request headers and the client should send the request body.
The server is switching protocols as requested, commonly during a WebSocket upgrade.
You typically will not alert on 1xx codes directly, but they may appear in low-level logs, traces, or proxy diagnostics.
Success
2xx means the request was successfully received, understood, and accepted. Monitoring dashboards usually treat these responses as healthy traffic.
The standard success response for GET and many other methods.
A new resource was created, commonly after a successful POST request.
The request was accepted for processing, but processing is not complete. Useful for async workflows.
The request succeeded but there is no response body, often used for DELETE operations.
For uptime checks, configure 200-299 as successful by default, then narrow to a specific code such as 200, 201, or 204 when the endpoint semantics require it.
Redirection
3xx codes tell the client to take additional action, usually by following a redirect to another URL.
The requested resource has permanently moved to a new URL.
The resource is temporarily available at a different URL.
The response can be found at another URI, usually after a POST or other non-GET request.
The cached version is still valid, commonly used with conditional GET requests.
A temporary redirect that preserves the original HTTP method.
Repeated or unexpected 3xx chains can indicate configuration issues, redirect loops, stale URLs, or a migration that was not completed cleanly.
Client Error
4xx codes mean the request has a client-side problem: bad syntax, missing authentication, missing permissions, rate limits, or a resource that does not exist.
The server cannot process the request because the syntax or submitted data is invalid.
Authentication is required, missing, or invalid.
The server understands the request but refuses to authorise it.
The requested resource does not exist. Very common in logs and monitoring.
The HTTP method is not allowed for the target resource.
The server timed out waiting for the request.
The request conflicts with the current state of the resource. Common in REST APIs.
The resource has been permanently removed and no forwarding address is known.
The request payload format is not supported by the server.
The request is syntactically valid but semantically invalid, often used for validation errors.
The client has sent too many requests in a given period and has been rate limited.
Track 4xx separately from 5xx. They are not always downtime, but spikes often reveal client bugs, broken links, frontend routing issues, expired tokens, or breaking API changes.
Server Error
5xx codes mean the server failed to fulfil an apparently valid request. These are usually true errors and strongly affect uptime and SLOs.
A generic error indicating the server hit an unexpected condition.
The server does not support the requested method or functionality.
A gateway or proxy received an invalid response from an upstream service.
The server is overloaded, unavailable, or down for maintenance.
A gateway or proxy did not receive a timely response from upstream.
The server cannot store the representation needed to complete the request.
The server detected an infinite loop while processing the request.
Alert quickly on sustained 5xx spikes from critical endpoints. Error-rate SLOs commonly treat 5xx responses as severe failures that consume error budget.
Status codes and uptime monitoring
Status codes become most useful in production when your uptime monitors, API monitors, and observability tools treat them as structured signals rather than generic log text.
Treat 2xx as success by default, optionally including specific 3xx responses when redirects are expected.
Track 4xx and 5xx separately so client-side issues do not hide true server incidents.
For APIs, use thresholds such as error rate (4xx + 5xx) above 1% for five minutes to avoid noisy single-request alerts.
For websites, route spikes in 404, 500, 502, 503, and 504 responses into your incident workflow.
Monitoring patterns by status code class
2xx: healthy
Count successful responses, latency, and response body validation. A 200 is healthy only if the body is also correct.
4xx: investigate
Watch spikes in 400, 401, 403, 404, 422, and 429. They often reveal broken clients, auth issues, frontend regressions, or rate limits.
5xx: alert
Sustained 500, 502, 503, and 504 responses from critical endpoints usually indicate incidents and should burn error budget.
Designing APIs with clear status codes
Good API design uses status codes consistently so clients, dashboards, alerts, and logs all tell the same story. The rules are simple, but they save hours during incidents.
Use 200, 201, and 204 for successful operations with clear semantics per method.
Use 400 or 422 for validation errors and include machine-readable error bodies.
Use 401 and 403 for authentication and permission problems, never 200 with an error payload.
Reserve 500-series responses for real server failures, not expected domain errors.
The practical takeaway
HTTP status codes are one of the cleanest signals developers have. They help you debug requests, design APIs, build uptime checks, separate client mistakes from server incidents, and decide when an alert should wake someone up.
When your application returns clear status codes and your monitoring system tracks them by class, your production dashboards become much easier to trust.
Written by
Dileep KK, MonitorGiant
LinkedIn21+ years in IT infrastructure management and observability. Built monitoring dashboards, custom alerting pipelines, and AI token-tracking systems across cloud platforms — AWS, GCP, and Azure — and for organisations spanning defence IT, IoT manufacturing, digital marketing, SaaS email, insurance broking, parliamentary digital services, and educational ERP. Active directory, SIEM, WAF, Cloudflare, MSSQL, Linux, Windows, Entra ID — operated at every layer of the stack.