What Do 500, 502, 503 and 504 Errors Mean?

You open your website and instead of your homepage, you get a stark white page: "500 Internal Server Error." Or maybe it's a 502, a 503, or a 504. They all look similar, they all mean your site isn't loading, and none of them tells you what actually went wrong.

These four codes belong to the same family — the 5xx server errors — but each one describes a different failure. Knowing which is which tells you where the problem lives, whether you can fix it yourself, and what to tell your hosting support if you can't. This guide decodes all four in plain English.

The Quick Answer: All Four Are Server-Side Problems

Here's the single most important thing to understand: 5xx errors are the server's problem, not the visitor's. Unlike a 404 (you typed a wrong address) or a 403 (you don't have permission), a 500-series error means something failed on the website's side — the server tried to fulfill the request and couldn't.

Each code narrows down where it failed:

Two pairs are easy to mix up, so запомните this:

• 500 vs 502: 500 = the application itself crashed. 502 = a middleman (proxy, CDN, load balancer) couldn't get a valid answer from the server behind it.
• 503 vs 504: 503 = the server said "no" on purpose (busy or maintaining). 504 = the server never answered in time.

Now let's go through each one properly.

500 Internal Server Error — "Something Broke on the Server"

The 500 is the vaguest of the four. By definition, it's the error a server returns "when an unexpected condition was encountered and no more specific message is suitable." In other words: something went wrong and the server won't tell the visitor exactly what.

Common causes

On typical shared or managed hosting, 500s almost always come from one of these:

• A crashing script. A PHP file, plugin, or theme with a fatal error (bad code after an update is the classic trigger) brings the whole page down.
• A broken .htaccess file. One wrong directive in .htaccess — a syntax error, an unsupported module — makes Apache refuse to serve the site entirely.
• PHP memory limits. A plugin or process exceeds the memory cap your host set, and the script dies mid-execution.
• File permission problems. If key files or folders have permissions the web server can't work with, requests fail before the application even runs.
• Corrupted core files. A failed WordPress or CMS update can leave half-written files that break everything.

What you can try yourself

1. Check your error logs. Your hosting control panel usually has an error log viewer — the actual PHP error message (with file name and line number) will be there, and it's worth a hundred guesses.
2. Undo the last change. Did it break right after a plugin update, theme change, or .htaccess edit? Roll that change back first.
3. Disable plugins one by one. On WordPress, rename the plugins folder via your file manager to disable everything at once; if the site returns, re-enable them individually to find the culprit.
4. Test a default .htaccess. Temporarily rename yours and let the CMS generate a fresh one — if the error vanishes, the old file had a bad rule.
5. Increase PHP memory (if your host allows it) via wp-config.php or the panel's PHP settings — a cheap fix when a hungry plugin is the cause.

If none of that helps, the problem is likely deeper in the server stack — time to contact support with the error log entry and the time the error occurred.

502 Bad Gateway — "The Proxy Got a Bad Answer"

A 502 means a gateway or proxy sat between the visitor and your web server, and couldn't get a usable response from the server behind it. The proxy is fine; the thing it's proxying to isn't answering properly.

Cloudflare's own documentation puts it plainly: a 502 (or 504) means Cloudflare "is unable to establish contact with your origin web server," and in the vast majority of cases the cause is at the origin — the hosting server — not the proxy.

Common causes

• Origin server down or unreachable. The web server crashed, restarted, or stopped accepting connections.
• Origin overloaded. A traffic spike or resource-heavy process makes the server stop responding in time.
• Wrong address or port. The proxy is pointed at an old IP or a service that isn't listening where expected.
• Firewall blocking. A rule on the server silently drops the proxy's requests.
• Broken compression. The origin serves gzip-compressed content with a mismatched content-length header or corrupt data, and the gateway rejects the response.
• Application timeout. A backend database or service the web server depends on times out or crashes mid-request.

Cloudflare-branded vs blank 502 — why the difference matters

If your site sits behind Cloudflare, you'll see one of two 502 pages, and knowing which determines where to look:

• Cloudflare-branded 502 page: your origin server returned the 502 itself. Start with your hosting provider — check server load, crash logs, and whether the application answered in time.
• Blank, unbranded 502 page: Cloudflare's edge generated the error, not your origin. This can point to a compression mismatch at the origin, or rarely a temporary routing shift during a data-center adjustment — which usually resolves within seconds.

What you can try yourself

1. Hard-refresh and clear cache — rule out a stale cached error page first.
2. Check whether it's just you — use a second network or a "down for everyone" checker.
3. Deactivate recent plugins/themes — a bad one can crash the application layer the proxy depends on.
4. Check server resources in your hosting panel — CPU or memory pegged at 100% explains a lot of 502s.
5. Look at the DNS — make sure the domain still points at the right server IP.

If the origin server itself is down or crashing, only your host can restart services or fix the underlying failure — send them the exact time, the URL, and whether the error page was Cloudflare-branded.

503 Service Unavailable — "The Server Is Refusing, On Purpose"

The 503 is unique in this family: the server is working fine, but it's deliberately saying "no" right now. It's almost always temporary — the server is either too busy or intentionally offline for maintenance. Well-behaved servers send a Retry-After header with the 503, telling clients how long to wait before trying again.

Common causes

• Overload or rate limiting. Too many simultaneous requests — a traffic spike, a bot flood, or your host's fair-use throttling — and the server starts turning requests away. Cloudflare's docs specifically advise checking whether your host rate-limits requests to the origin.
• Maintenance mode. Updates, migrations, or scheduled work put the site in a deliberate "come back later" state.
• Stopped services. The web server is up but the application pool, PHP service, or database behind it has stopped.
• Resource exhaustion. The server ran out of worker processes, connections, or memory — every slot is full, so new requests get refused.

The Retry-After header — what it tells you

If the 503 response includes a Retry-After header (a number of seconds, or a timestamp), that's the server telling you exactly when to come back. Search engines respect it too — Google will retry crawling later rather than treating the page as broken. A 503 with Retry-After during maintenance is actually good practice, not a bug.

What you can try yourself

1. Wait and retry. Many 503s clear on their own within minutes — traffic spikes pass, maintenance finishes.
2. Check for maintenance mode. Did you (or an auto-update) trigger one? WordPress leaves a .maintenance file behind if an update is interrupted — deleting it can instantly fix the site.
3. Deactivate the newest plugin first if the error appeared after an update.
4. Check your resource usage in the hosting panel — if CPU/memory/connections are maxed out, you know it's capacity, not a bug.
5. View the page source of the error — if it mentions Cloudflare, the issue may be between Cloudflare and your origin; if it doesn't, ask your host whether they rate-limit origin requests.

Contact your host when: the 503 has lasted over an hour with no change on your side, your panel is also returning 503, or a service won't restart from the control panel. Send them the error code, the exact time with timezone, and the failing URL.

504 Gateway Timeout — "The Proxy Gave Up Waiting"

A 504 is the 502's patient sibling: the upstream server was reachable, but it took longer than the proxy's timeout to respond — so the proxy gave up and told the visitor. Per RFC 9110, the server "did not receive a timely response" from the inbound server it needed to complete the request. It is almost always the website's problem, not the visitor's device or connection.

Common causes

• Slow database queries. An unindexed query or an N+1 query pattern makes a page take 30+ seconds to build; the proxy's timer (often 30–60 seconds) expires first.
• Long-running scripts. Imports, exports, backups, or report generation running inside a normal web request instead of a background job.
• Overloaded application server. The app is alive but every worker is busy, so the request sits in a queue until the timer runs out.
• Timeouts set too low. The proxy's read timeout is shorter than the application's legitimate execution time — a configuration mismatch rather than a real failure.

502 vs 504: invalid answer vs no answer in time

This is the cleanest distinction in the whole family:

• 502: the upstream replied with garbage (invalid response) or refused the connection outright.
• 504: the upstream was reachable but never replied in time.

And one Cloudflare-specific note: behind Cloudflare, an origin that accepts the connection but sends nothing fires Cloudflare's own 524 code (at ~100–120 seconds), not a 504. So a plain 504 seen through Cloudflare usually traces to a second proxy layer or the origin's own gateway timing out.

What you can try yourself

1. Reload after a minute. Transient 504s from brief spikes clear on their own — this is the first and often the only step a visitor needs.
2. Measure the response time with curl -w "%{time_starttransfer}\n" against the slow URL — if it's consistently near the timeout value, you've confirmed a slow backend, not a network flake.
3. Check application logs for slow queries, hangs, or exceptions around the time of the error.
4. Disable heavy plugins or pause cron jobs temporarily to see if the timeouts stop.
5. Don't just raise timeouts. Increasing the proxy timeout papers over the delay; the real fix is making the upstream faster — indexing the slow query or moving the long job to a background queue.

If you're on shared hosting and can't touch server configuration, slow-backend 504s are a strong signal the site has outgrown the plan — which is exactly what our hosting plan guide helps you evaluate.

What You Can Fix Yourself vs What Needs Your Host

Not every 5xx error is yours to solve. Here's the dividing line:

Try yourself first:

• Hard refresh / clear browser cache (rules out stale error pages)
• Undo the last change (plugin update, .htaccess edit, new code)
• Disable plugins one by one (WordPress)
• Read the error logs in your control panel
• Check resource usage (CPU, memory, connections)
• Confirm DNS still points at the right server
• Wait a few minutes and retry (transient spikes, maintenance windows)

Contact your hosting support when:

• Error logs point at server-level failures you can't access
• The server, PHP service, or database won't restart from your panel
• Resource usage is maxed out and you can't find the cause
• The error persists over an hour with nothing changed on your side
• Your hosting dashboard itself is erroring

What to send support (this gets you a faster answer): the exact error code, the failing URL, the time with timezone, whether the error page mentions Cloudflare (or any CDN/proxy), and the relevant error-log lines if you can see them.

Frequently Asked Questions

Are 500 errors bad for SEO?

A few transient 500s won't hurt you — Google understands servers hiccup. But persistent 5xx errors are a real problem: if Googlebot repeatedly can't fetch your pages, those pages can be dropped from the index and rankings slide. Fix recurring server errors quickly, and use 503 with Retry-After (not 500) during planned maintenance so crawlers know to come back.

What's the difference between a 502 and a 504?

Both mean a proxy failed to relay a response from the upstream server. The difference is what went wrong: 502 = the upstream responded with something invalid, or refused the connection. 504 = the upstream was reachable but took longer than the proxy's timeout to answer. In both cases the fault is upstream, not with the visitor.

My site shows 503 only sometimes. Is that normal?

Intermittent 503s usually mean the server is brushing against a capacity limit — fine at quiet hours, refusing requests at peak traffic. Check your resource graphs in the hosting panel: if CPU, memory, or concurrent connections spike at the same times the 503s appear, the site needs more headroom (optimization, caching, or a bigger plan).

Can a 504 be caused by my internet connection?

Almost never. A 504 means a server-side proxy gave up waiting on an upstream server — the failure is between two servers, not between you and the site. Slow visitor connections produce different errors (like 408 Request Timeout). If you see a 504, the website's backend is too slow.

Why do I see a Cloudflare error page instead of my host's?

When your site uses Cloudflare, Cloudflare sits between visitors and your origin server. If the origin fails, Cloudflare generates its own branded error page (502, 503, 504, or Cloudflare-specific codes like 521/522/524) rather than passing through whatever your host produced. The branding tells you the failure was detected at the proxy layer — but the root cause is still almost always the origin.

I fixed the cause but the error page won't go away. Why?

Stale cache. Your browser, your CDN, or a caching plugin may be serving the saved error page. Hard-refresh (Ctrl+F5), purge the CDN/plugin cache, and check again. If the error persists after purging everywhere, the underlying cause isn't actually fixed yet.

Seeing these errors regularly? Occasional 5xx errors happen to everyone, but if your site throws them weekly, the problem is usually capacity — not luck. Our guide to choosing a hosting plan walks through how to tell whether your current setup is keeping up with your site, and what to look for when it isn't.