Troubleshooting
HTTP 500, 502 and 503 errors explained for website owners
A browser saying “server error” does not identify the failed component. The useful part of an HTTP status code is that it narrows the layer you should investigate before changing anything.
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.