502 vs 503 vs 504: what's the difference between these server errors?
502 Bad Gateway, 503 Service Unavailable and 504 Gateway Timeout all mean the same thing to a visitor: the website is having a problem on its side. But each one points to a different failure, which matters if you're trying to judge how long it'll last or you're the one who has to fix it. Here's the difference in plain English.
First, what's a "gateway"?
Most websites don't send you pages straight from the computer that builds them. In front sits a gateway, also called a reverse proxy: a load balancer, a CDN like Cloudflare, or a web server such as Nginx. It receives your request, passes it to the application server behind it (running PHP, Node.js, Python and so on), and relays the answer back. 502 and 504 describe what went wrong between those two; 503 is the server saying it can't take your request right now.
The difference at a glance
| Error | In plain words | Who reports it | Typical cause | Usually lasts |
|---|---|---|---|---|
| 502 Bad Gateway | "I got a broken answer" | The gateway | App crashed, restarting or refusing connections | Seconds to minutes |
| 503 Service Unavailable | "Not now, try later" | The server itself, or the gateway on its behalf | Overload or planned maintenance | Minutes to hours |
| 504 Gateway Timeout | "I got no answer in time" | The gateway | App too slow, stuck, or unreachable | Seconds to minutes |
In every case the problem is on the website's side, not yours.
502 Bad Gateway
The gateway reached the application server but got back something invalid: the connection was refused or closed, or the reply was garbled. You'll often see it as "502 Bad Gateway nginx" or a Cloudflare 502 page.
Common causes: the app crashed or is restarting during a deployment, PHP-FPM or the Node/Python process isn't running, it ran out of memory, or the gateway is pointed at the wrong port or socket.
If you run the site: check that the application process is running, restart it, and read its logs and the gateway's error log (for Nginx, usually /var/log/nginx/error.log) around the time of the errors. Lines like "connection refused" or "upstream prematurely closed connection" point straight at the app.
503 Service Unavailable
The server is up but deliberately not handling requests right now, either because it's overloaded or because it's in maintenance mode. A well-configured site also sends a Retry-After header saying when to come back.
Common causes: a traffic spike, hitting the hosting plan's resource limits, a maintenance mode left switched on after an update (common with WordPress), or an app with no healthy servers left behind the load balancer.
If you run the site: check resource usage and limits in your hosting panel, turn off maintenance mode if an update finished, add caching to cut load, and scale up if spikes are regular. For planned maintenance, a 503 with Retry-After is the correct response: it tells search engines the outage is temporary, so a short maintenance window won't hurt your rankings.
One exception: some bot-protection services use 503 for their "checking your browser" pages. That's why checkers can get false "down" results, and why ours looks at the page content before calling a 503 an outage.
504 Gateway Timeout
The gateway passed your request on and waited, but the application server didn't respond before the gateway's time limit ran out (for example, Nginx's default proxy timeout is 60 seconds).
Common causes: a slow database query, a page doing heavy work while you wait (reports, exports, large uploads), a call to an outside service that's hanging, or a server so busy it can't get to new requests.
If you run the site: find the slow requests in your logs or monitoring, fix slow queries and add caching, and move long jobs to background tasks. Raising the timeout can hide the symptom for a while, but the page will still feel broken to visitors.
Behind Cloudflare, the equivalent errors are 522 (couldn't connect to the server at all) and 524 (connected, but the response took too long). See our guide to error 522.
What to do as a visitor
- Wait a minute and reload. 502s and 504s are often over within seconds; a 503 for maintenance can take longer.
- Check the site on CheckIfSiteDown to confirm it's down for everyone, not just you.
- Don't keep hammering refresh. On an overloaded site, every reload adds to the pile, and you may end up with a 429 Too Many Requests on top.
- If you were paying for something when the error appeared, check your email or bank for a confirmation before trying again, so you aren't charged twice.
What about 500?
500 Internal Server Error is the catch-all: the application itself hit an error while building the page, with no gateway problem involved. It's the website's problem too. Our HTTP status codes guide covers 500 and every other common code.
The short version
502: the gateway got a broken answer from the server. 503: the server is overloaded or in maintenance and says try later. 504: the gateway gave up waiting for the server. All three are on the website's side. Visitors should wait and reload, and site owners should start with the application's logs. When in doubt, run a check.