HTTP Status Codes Explained: 401, 403, 404, 429, 500, 502, 503, 504

An HTTP error code is not the full diagnosis, but it tells you which direction to investigate.

When debugging websites and APIs, developers frequently encounter 401, 403, 404, 429, 500, 502, 503, and 504.

Use Duck Cloud's HTTP Status Code Lookup for a quick reference and the Website Status Checker to inspect a public URL.

401 Unauthorized

A 401 generally indicates that valid authentication credentials are required or the provided credentials were not accepted.

Check:

• missing Authorization header;
• expired access token;
• invalid token signature;
• wrong authentication scheme;
• incorrect API key;
• session expiration.

For JWT-based systems, separate token decoding from actual signature and claim verification.

403 Forbidden

A 403 means the server understood the request but refuses to fulfill it.

Common causes include:

• authenticated user lacks permission;
• IP or country rule blocks the request;
• web application firewall rule;
• file-system permission;
• origin access restriction;
• missing required role or scope.

A 403 is not always an authentication failure. The user may be authenticated correctly but not authorized for that resource.

404 Not Found

A 404 indicates the requested resource was not found.

Check:

• spelling and path case;
• route configuration;
• dynamic route parameters;
• deployment output;
• reverse-proxy rewrites;
• removed files;
• API version changes.

For migrated websites, trace redirects and update internal links so users do not continue reaching old URLs.

429 Too Many Requests

A 429 indicates rate limiting.

Check:

• request frequency;
• client retry loops;
• concurrency;
• shared IP limits;
• API quotas;
• Retry-After headers when provided;
• background jobs that accidentally run more often than intended.

Use backoff and respect the service's published rate-limit behavior.

500 Internal Server Error

A 500 is a generic server-side failure.

Look at application logs around the exact request time.

Common causes include:

• unhandled exceptions;
• missing environment variables;
• database errors;
• template failures;
• incompatible runtime versions;
• bad deployment artifacts.

Do not expose internal stack traces or secrets to public users.

502 Bad Gateway

A 502 often appears when a reverse proxy or gateway cannot get a valid response from an upstream service.

Check:

• whether the application process is running;
• upstream host and port;
• container networking;
• TLS between proxy and origin;
• firewall rules;
• process crashes;
• malformed upstream responses.

If you use Cloudflare, Nginx, Traefik, a load balancer, or a platform proxy, identify which layer generated the 502.

503 Service Unavailable

A 503 often indicates temporary unavailability.

Possible causes:

• planned maintenance;
• overloaded application;
• unhealthy backend pool;
• autoscaling delay;
• database outage;
• deployment transition;
• dependency failure.

A 503 should normally be treated as a service-health problem rather than a missing route.

504 Gateway Timeout

A 504 occurs when a gateway waited too long for an upstream response.

Investigate:

• slow database queries;
• external API latency;
• long synchronous jobs;
• deadlocks;
• overloaded servers;
• network timeouts;
• upstream timeout settings.

Increasing the timeout without fixing the underlying slow operation may only make users wait longer.

Check headers and redirects too

The status code alone may not explain everything.

Use the HTTP Header Checker to inspect headers and the Redirect Checker to determine whether the failing URL is only one step in a larger redirect chain.

API debugging workflow

When an API request fails:

1. record method and URL;
2. record status code;
3. inspect response Content-Type;
4. preserve the raw response body;
5. record request or trace ID;
6. check authentication separately from authorization;
7. compare the request with API documentation;
8. inspect server logs if you own the backend.

Do not put live secrets into bug reports or screenshots.

HTTP error checklist

• 401: verify authentication.
• 403: verify authorization and access rules.
• 404: verify route and resource.
• 429: reduce request rate and inspect retry behavior.
• 500: inspect application errors.
• 502: inspect proxy-to-upstream connectivity.
• 503: inspect service health and capacity.
• 504: inspect slow upstream operations and timeouts.

Status codes are most useful when combined with headers, logs, request IDs, and a clear understanding of which infrastructure layer generated the response.