The Ultimate Guide to HTTP Status Codes

Every response your web server sends to a browser includes an HTTP status code — a three-digit number that tells the client what happened with its request. Understanding these codes is fundamental to web development, debugging, and monitoring.

This guide covers every major status code: what it means, what causes it, and what to do about it.

How Status Codes Are Structured

HTTP status codes are grouped by their first digit:

• 1xx — Informational — The request was received, processing continues
• 2xx — Success — The request was successfully received and processed
• 3xx — Redirection — Further action is needed to complete the request
• 4xx — Client errors — The request contains bad syntax or cannot be fulfilled
• 5xx — Server errors — The server failed to fulfil an apparently valid request

The client (browser or API consumer) determines what to do based on the status code. A browser knows to follow a 301 redirect. An HTTP client knows to retry a 429 with backoff. Knowing what each code means helps you debug problems and build applications that handle them correctly.

2xx Success Codes

200 OK

The standard success response. The request was received, understood, and processed. The response body contains the requested resource.

This is what you want to see for any successful request — a webpage loading, an API call returning data, a file being served.

201 Created

Returned when a POST request successfully creates a new resource. REST APIs commonly return 201 after a successful POST /resources call, often with the newly created resource in the response body and a Location header pointing to it.

204 No Content

The server successfully processed the request but has no content to return. Common for:

• DELETE requests (resource deleted, nothing to return)
• PUT/PATCH requests that update without returning data
• CORS preflight OPTIONS responses

206 Partial Content

The server is delivering only part of the resource, typically in response to a Range header from the client. Used for resumable downloads and video streaming where clients request specific byte ranges.

3xx Redirection Codes

301 Moved Permanently

The requested resource has been permanently moved to a new URL. Browsers and search engines should update their records and use the new URL going forward.

Common use cases:

• Redirecting HTTP to HTTPS
• Redirecting www.domain.com to domain.com (or vice versa)
• Site migration to a new domain
• Permanent URL restructuring

301 redirects pass link equity (SEO value) to the new URL — search engines transfer ranking signals to the new location.

302 Found (Temporary Redirect)

The resource is temporarily at a different URL. Browsers follow the redirect but don't update their bookmarks. Search engines don't transfer link equity.

Use 302 for genuinely temporary redirects: A/B testing, maintenance redirects, redirects that will change.

303 See Other

After a POST request, redirect the client to a different URL with a GET request. Used in the Post/Redirect/Get pattern to prevent form resubmission on page refresh.

304 Not Modified

The resource hasn't changed since the client's cached version. The server skips sending the response body — the client uses its cache. Relies on ETag or Last-Modified headers.

This is good — it means caching is working correctly and requests are faster.

307 Temporary Redirect / 308 Permanent Redirect

Like 302 and 301 respectively, but with an important difference: the HTTP method must not change. A 307/308 redirect preserves POST, PUT, DELETE. A 301/302 typically downgrades to GET.

Use 307/308 when redirecting form submissions or API requests where the method matters.

4xx Client Error Codes

400 Bad Request

The server can't process the request because of a client-side error — malformed syntax, invalid request message framing, or deceptive request routing.

Common causes:

• Malformed JSON in the request body
• Missing required parameters
• Invalid data types in a request
• Corrupted request data

Fix: Check the request format against the API documentation. Log the request body on the server side to see what's being received.

401 Unauthorized

The request requires authentication, and either no credentials were provided or the provided credentials are invalid.

The name is slightly misleading — it actually means "unauthenticated" (no valid credentials), not "unauthorised" (authenticated but lacking permission, which is 403).

Common causes:

• Missing or expired API key or token
• Invalid Bearer token in the Authorization header
• Session expired

Fix: Re-authenticate and retry with fresh credentials.

403 Forbidden

The server understood the request but refuses to authorise it. The client is authenticated but doesn't have permission to access this resource.

Common causes:

• User lacks permission for the requested resource
• IP address blocked by the server
• Directory listing disabled and no index file
• File permissions on the server too restrictive

Fix: Check access control configuration. Verify the user has the required permissions. See our full guide: 403 forbidden error fix.

404 Not Found

The server can't find the requested URL. Either the resource doesn't exist or the URL is wrong.

Common causes:

• Broken or mistyped URL
• Resource was deleted or moved without a redirect
• Case sensitivity issue (URLs are case-sensitive on Linux servers)
• Application routing not configured correctly

Fix: Verify the URL. If the resource was moved, implement a 301 redirect. Check server routing configuration.

405 Method Not Allowed

The HTTP method used isn't supported for this URL. The server returns an Allow header listing the supported methods.

Example: Sending a DELETE request to an endpoint that only supports GET and POST.

Fix: Check the API documentation for the correct HTTP method. Ensure your client is using the right verb.

408 Request Timeout

The server timed out waiting for the request. The client took too long to send the complete request.

Fix: Check client-side timeouts, network conditions, and whether a large request body is causing the delay.

409 Conflict

The request conflicts with the current state of the resource. Common in REST APIs when:

• Trying to create a resource that already exists
• Editing a resource that has been modified by another request (optimistic locking)
• Violating a uniqueness constraint

410 Gone

Like 404, but permanent — the resource was here and won't be coming back. More explicit than 404 for intentionally removed resources.

Useful for retired API versions or content that has been deliberately removed. Search engines can de-index 410 pages more quickly than 404 pages.

422 Unprocessable Entity

The request was well-formed but contained semantic errors. Common in REST APIs for:

• Validation failures (required field missing, value out of range)
• Business logic violations

Often returned with an error body detailing which fields failed validation.

429 Too Many Requests

The client has sent too many requests in a given time period — rate limiting.

The response typically includes a Retry-After header indicating when to try again.

Fix: Implement exponential backoff in your client. Reduce request frequency. Consider whether you need a higher rate limit tier.

5xx Server Error Codes

5xx errors mean the server failed — the client's request was valid, but the server couldn't fulfil it. These are the codes that require server-side investigation.

500 Internal Server Error

A generic catch-all for server errors. Something went wrong server-side, but the server didn't have a more specific error to report.

Common causes:

• Unhandled exception in application code
• PHP fatal error
• Database query failure
• Misconfiguration in application logic

Fix: Check server error logs. 500 errors always produce log entries — the log contains the actual cause. See 500 internal server error fix.

502 Bad Gateway

A server acting as a gateway (reverse proxy, load balancer) received an invalid response from an upstream server.

Common causes:

• Application server (PHP-FPM, Node.js, Gunicorn) crashed
• Application server restarting
• Nginx/Apache can't reach the backend on the configured port

Fix: Restart the application server process. Check that it's listening on the correct port. See 502 bad gateway fix.

503 Service Unavailable

The server is temporarily unable to handle the request — typically due to overload or maintenance.

Common causes:

• Server at capacity (CPU, memory, connection limits)
• Application in maintenance mode
• Database connection pool exhausted
• Rate limiting at the infrastructure level

Fix: Scale resources, optimise application code, or wait for the load to subside. See 503 service unavailable fix.

504 Gateway Timeout

A server acting as a gateway didn't receive a timely response from an upstream server.

Common causes:

• Application server too slow (slow database queries, heavy computation)
• Database overloaded
• External API call timing out within your application

Fix: Identify and optimise slow operations. Increase timeout values if the operation is legitimately slow. Add caching where appropriate. See 504 gateway timeout meaning.

521, 522, 524 (Cloudflare-Specific)

If you're using Cloudflare:

• 521 — Cloudflare can't connect to your origin server (origin is down or refusing connections)
• 522 — Connection to origin timed out
• 524 — A timeout occurred after Cloudflare connected

These all point to problems between Cloudflare and your origin server. See dedicated guides: Cloudflare error 521, Cloudflare error 522, Cloudflare error 524.

Status Codes and Uptime Monitoring

HTTP status codes are the primary signal that uptime monitoring uses to evaluate whether your website is healthy. A monitor that receives a 200 marks the check as successful. A monitor that receives a 500, 502, or 503 — or no response at all — marks it as failed and triggers an alert.

This is why a good health check endpoint matters. Rather than checking your homepage (which involves full page rendering, database queries, and all your application logic), a dedicated /health endpoint gives monitoring tools a fast, reliable signal:

@app.route('/health')
def health_check():
    return {'status': 'ok'}, 200

Domain Monitor monitors your URLs every minute from multiple global locations and alerts you the moment a non-2xx response (or no response) is detected. Create a free account and add monitors for your critical endpoints — you'll catch problems the moment they occur rather than when users report them.

For deeper monitoring guidance, see the ultimate guide to website uptime monitoring.

Quick Reference

Related Articles

• The Ultimate Guide to DNS - How the Domain Name System Works
• The Ultimate Guide to Website Security for Developers
• The Top 5 Most Common Website HTTP Error Codes To Look Out For [And How To Fix Them]