A 5xx error is, in one narrow sense, good news: something is alive and talking to you. A server received your request, tried to handle it, and failed. That is meaningfully different from a site that is off, and it points at a different set of causes.
Nearly all modern sites run two pieces: a web server at the front — Nginx, Apache, a load balancer, a CDN — and an application behind it that generates pages. The front end takes the request and hands it to the application.
502, 503 and 504 all describe that handoff failing, in three distinct ways.
502 Bad Gateway — the application did not answer properly
The web server forwarded the request and got back either nothing or something it could not understand.
Almost always the application process is not running. It crashed, it was never started, or it is listening somewhere the web server is not looking.
What to check, in order:
- Is the application process running?
systemctl status your-app,pm2 list,docker ps— whatever supervises it. This is the answer most of the time. - Is it listening where the web server expects? A mismatch between the port or socket in the web server config and the one the application actually binds to produces a permanent 502 that looks like a crash. Check both sides.
- Did it crash on startup? A 502 immediately after a deploy usually means the new version failed to boot — a syntax error, a missing environment variable, a failed database connection. The application log will say; the web server log will only say it could not reach it.
- Is it out of memory? A process killed by the OOM killer disappears without a graceful error.
dmesg | grep -i oomwill show it.
On PHP sites, 502 usually means PHP-FPM is down or its socket path is wrong. Restarting PHP-FPM is the standard first move.
503 Service Unavailable — deliberately not serving right now
Unlike 502, a 503 is often intentional. It means the server is up and choosing not to handle the request.
Common causes:
- Maintenance mode. Many CMS platforms return 503 during an update. WordPress leaves a
.maintenancefile behind if an update fails partway; deleting it clears the error. - Overload. The application is at capacity and refusing rather than queueing. A traffic spike, a slow database backing everything up, or too few worker processes.
- Rate limiting. A security service or WAF deciding there is too much traffic from somewhere.
- Health check failure. A load balancer that has marked every backend unhealthy has nowhere to send traffic and returns 503.
A 503 is the one error that legitimately fixes itself. If it is load-related, traffic subsiding resolves it — which is also why it is easy to dismiss and let recur.
Worth knowing: a correct 503 includes a Retry-After header, and search engines treat a short 503 as "come back later" rather than de-indexing. That makes 503 the right status for planned maintenance, and the wrong thing to replace with a 200 page saying "we'll be back soon" — which tells search engines the maintenance notice is your content.
504 Gateway Timeout — the application took too long
The web server reached the application, waited, and gave up before a response arrived.
This is the most informative of the three, because it means the code is running and simply too slow. It rules out crashes and configuration problems entirely.
Usual causes:
- A slow database query. By far the most common. A query with no index against a table that has grown, or a report doing full table scans.
- An external API call with no timeout. Your page calls a third-party service which is slow or unresponsive, and your request waits on someone else's outage. Any outbound call needs a timeout shorter than your own.
- A genuinely long operation in a web request — a large import, a report, an image batch. Work like that belongs in a background job, not in the request cycle.
- A deadlock or lock contention, where requests wait on each other.
Raising the timeout is not the fix. It converts a 504 into a page that takes 60 seconds, which users abandon anyway while your worker processes stay occupied — often turning a slow page into a site-wide outage as the pool exhausts.
Telling them apart quickly
| What happened | Most likely cause | |
|---|---|---|
| 502 | No usable response from the app | Process crashed or not running |
| 503 | Server refused to handle it | Maintenance, overload, rate limit |
| 504 | App too slow to answer | Slow query or external API |
Confirm which you are actually getting with the Website Down Checker, which reports the status code directly. Browsers sometimes render a host's branded error page, and those do not always match the underlying code.
Where the real answer is
Your application log, not the web server log. This is the single most useful thing to know here.
The web server log records that it could not reach or could not wait for the application. That tells you the symptom. The application log records the exception, the failed database connection, the missing variable — the cause.
For a 502 immediately after a deploy, the application log will usually name the problem on the first line of its startup attempt.
Intermittent 5xx errors
Errors that come and go are the frustrating case, and they are almost always capacity rather than correctness.
The site works at low traffic and fails at peak, because there are not enough workers, connections or memory to handle concurrency. Under load, one slow query holds a connection, connections run out, and everything queues — so the failure appears at some threshold rather than consistently.
The other pattern worth knowing: one server in a pool is broken while the others are fine. Requests fail roughly one time in N, which looks random until you notice the ratio.
Preventing the recurrence
Set timeouts on every outbound call. A third party's outage should degrade one feature, not take your site down.
Fix the slow queries rather than raising limits. Every timeout increase is borrowed time.
Monitor externally. Intermittent 5xx errors are invisible from inside — the requests that failed are the ones nobody is looking at.
Use a real 503 with Retry-After for planned maintenance, so search engines wait rather than re-evaluating your site.
If you are still narrowing down what is broken, the full diagnostic checklist covers the steps before and after this one.