HTTP 500, 502 and 503 errors explained for website owners

500 vs 503: internal error vs temporary unavailability

HTTP 500 means the server hit an unexpected condition and could not complete the request. HTTP 503 means the service is currently unavailable, commonly because it is overloaded, in maintenance, or cannot accept work at that moment.

For a 500, start with the application and server logs for the failed request. For a 503, also check service health, worker and resource limits, maintenance state, and any proxy or upstream layer. A 503 response can include a Retry-After header to tell clients when to try again.

500: the application or server hit an internal error

HTTP 500 is a general server-side failure. Common causes include application exceptions, broken configuration, permission problems, failed dependencies, incompatible updates, or code paths that did not handle an unexpected condition.

The next step is usually the relevant application, PHP, web-server, or framework log around the exact time of the request.

502: a gateway could not get a valid upstream response

A reverse proxy may return 502 when the upstream application is stopped, listening on the wrong address, crashing during requests, timing out incorrectly, or returning something the proxy cannot use.

Check both sides of the connection: the proxy configuration and the application process it is trying to reach.

503: the service is temporarily unavailable

HTTP 503 is often used when a service is overloaded, intentionally in maintenance, unavailable behind a proxy, or unable to accept more work. Resource exhaustion and worker limits can also surface as 503 responses depending on the stack.

Collect evidence before restarting everything

Record the exact URL, status code, time, recent deployment or configuration change, resource usage, and relevant logs. Restarting a service can restore traffic, but it can also erase the state that would have explained why the failure happened.

The status code is the beginning of the diagnosis

The same code can have different root causes on different stacks. Use it to choose the next layer to inspect, then confirm the actual failure with logs, process state, dependency checks, and resource data.