500, 502 Bad Gateway, 503 and 504 errors — what they mean and who to call when they hit your site

If you are seeing this error on someone else's website — a shop, a bank, a public authority — it is not a problem with your computer or your connection. A code starting with 5 means the server on the other side has failed. Reload the page in a few minutes; if that does not help, try again later. There is nothing more you can do from your side of the screen.

If it is your own website, the error code is worth more than it seems. It does not just say that "something is broken". It says on which stretch of the path from the browser to the database something failed — and that decides who needs to be called: the hosting company, the agency that built the site, or the provider of a service that sits in between.

This article is about reading that code. How to find out about an error before a customer calls is covered in our piece on website monitoring.

Four codes, four places in the chain

When someone opens a web page, their browser rarely talks directly to the program that builds that page. In between there is usually an intermediary — a content delivery network (CDN), a web server that receives the traffic, or another proxy server — and behind it the application: WordPress, a shop, a content management system. The application in turn reaches out to a database and to external services. Each of these elements can fail, and each fails differently.

All four codes are defined in the HTTP specification, and each definition points to where the failure happened:

• 500 — the server encountered "an unexpected condition" that prevented it from fulfilling the request. A failure in the application.
• 502 — the server, acting as a gateway or proxy, "received an invalid response" from the server it contacted. A failure between the intermediary and the application: the application replied, but badly — or did not reply at all because it is not running.
• 503 — the server is "currently unable to handle the request due to a temporary overload or scheduled maintenance". A temporary refusal: overload or maintenance work.
• 504 — the intermediary "did not receive a timely response" from the server behind it. The application did not make it in time.

This is the first rule for reading errors: the same outage always looks the same from the browser — the page does not open — but the code tells you where to look. A contractor who starts every incident by restarting the server is ignoring half of the information the server has given them.

500 error — internal server error

The 500 error is the most searched-for server code and the most misunderstood. It sounds like "the server is broken". It means something narrower: the program that was supposed to handle this particular request ran into a situation it did not anticipate and stopped. The server is working — after all, it answered with a code. What failed is the application, and often only for one kind of request.

We have a recent example from our own site. For several hours, uploading files to our content management system ended in a 500 error, and in our working notes it went into the "production outage — waiting" column. The website was working normally the whole time, and other saves went through without a problem. The cause turned out to be the shape of the request itself: one field was being sent in a format the application did not accept for file uploads. Once the request was changed, the same server accepted the same file on the first attempt. The lesson is general: a 500 says that something crashed in the code handling this request. Before anyone goes looking for a server outage, it is worth checking whether the error appears everywhere or only for one action.

On WordPress sites, the cause of a 500 error is usually one of three things:

• A plugin or theme — most often right after an update, when the new version is incompatible with the rest. That is why updates are done one item at a time, with a backup first: then you know what to roll back.
• The PHP version — a change on the server after which older code stops working. This can also happen without any action on your part, when the hosting provider switches off an old version.
• A resource limit — a script exceeded the memory or time the server allows. Typical during large imports, thumbnail generation and backups made by a plugin.

The server error log — available in the hosting control panel or from your contractor — usually states the cause directly, with the file name and line number. So the first question to ask your contractor about a 500 error is: what does the error log say for that minute? The answer "we restarted the server and it works" means nobody looked, and the error will come back with the next identical request.

How to fix a 500 error, step by step

This is the order that most often gets you to the cause by the shortest route — including when your contractor is doing it and you want to know whether they are doing it well:

1. Does the error appear everywhere, or for one action? Home page, subpage, admin panel, form, cart. An error for one action only narrows the search to one feature — and almost rules out a "server outage".
2. The error log for that minute. In the hosting panel or from your contractor. In WordPress you can also switch on logging to a file in the wp-content folder — a setting that writes errors to a log instead of showing them to visitors.
3. The most recent change. An update, a new plugin, a PHP version change, a deployment. If the error started right after it, undoing that one change is faster than hunting for the cause.
4. Disabling the culprit plugin without the admin panel. If you cannot get into the panel, a plugin is disabled by renaming its folder on the server — WordPress then stops loading it. We describe the same method in the article on updates.
5. A backup, if the cause is not visible. Restoring the state from before the outage is a decision about how much data since then you are prepared to lose — which is why the owner makes it, and why the precondition is a backup that someone has actually restored at least once.

For 502 and 503 the order is similar, except that step two concerns the intermediary's log and the server load, and step three concerns deployments and changes to the hosting plan.

"There has been a critical error on this website"

Owners of WordPress sites see this message more often than a bare 500 code. WordPress itself, since version 5.2, catches the most serious application errors: instead of a blank white page it shows visitors a message that the site is experiencing technical difficulties.

What happens in the background matters more. According to the WordPress core team's note, the system then sends a message to the site administrator's email address with a secret link to recovery mode. Once someone follows that link, the plugins or themes causing the error are paused — but only for the person who used the link. They can log into the admin panel, deactivate the culprit plugin or restore the previous version, while visitors still see the error message.

The mechanism works well, on one condition: someone has to receive that email. The administrator address is set during installation and rarely revisited. If the site was set up years ago by an agency or by an employee who has since left, the recovery link lands in a mailbox nobody reads. It is the same problem we describe in our piece on website maintenance services in the context of the domain and access: contact addresses in the systems your site depends on should lead to someone in your company. Checking takes a minute — in the WordPress admin panel, under general settings.

502 Bad Gateway — what it means

"Bad Gateway" means roughly that the gateway got something wrong. The gateway is the intermediary: the server that receives the request from the browser and passes it on to the application. A 502 error means that the intermediary asked the application for the page, and what came back could not be sent on — or nothing came back, because the application did not accept the connection.

In practice, a 502 most often means that the program that produces the site behind the intermediary is not running or is restarting right now. The web server is up, the network works, but the process that was supposed to generate the page has died — out of memory, after an error, or while a new version was being deployed. That is why a 502 can be short-lived: it appears for a few dozen seconds during an update and disappears.

What this means for the owner:

• A 502 lasting seconds during a deployment is usually a result of how deployments are done, not an outage. It can be avoided, but that is a decision about the deployment process, not a repair.
• A 502 that keeps coming back without deployments is an application that keeps crashing. The question for your contractor: why does the process stop, and what is in its log?
• A 502 from your CDN provider — if the site sits behind a content delivery network — means the CDN is working but cannot reach your server. Check the server first, not the CDN.

The same code often appears with extra words attached: "502 Bad Gateway nginx", "HTTP 502", "502 Proxy Error". They all mean the same thing. The word that follows the code is simply the name of the intermediary that reported it — here, the nginx web server — which tells you whose log to open.

503 error — service temporarily unavailable

503 is the only one of these codes that a site should sometimes return on purpose. The specification provides for two situations: overload and planned maintenance. In both cases the server may add a Retry-After header saying when it is worth trying again. The variant "503 Service Temporarily Unavailable", which many servers display, is the same code with a slightly longer label.

Overload means the server is receiving more requests than it can handle and turns some of them away rather than serving all of them too slowly. On shared hosting, a 503 can also be the way the provider signals that the site has exceeded its allocated resources. If it appears regularly at peak times, that is a sign the hosting plan is too small or the site uses too much per page view — which usually also shows up in Core Web Vitals.

Planned maintenance is the second situation, and the rule here is simple: if the site is going to be unavailable for a while, let it answer with a 503, not with a "down for maintenance" page returning 200. To a visitor they look the same. To a search engine, the first means "come back later", the second means "this is what the page looks like now". WordPress does this itself during updates: for the duration of the installation it shows a short maintenance message with exactly this code, 503, and a Retry-After header set to 600 seconds — that is how it is written in its source code.

504 Gateway Timeout

504 is a close relative of 502, with one difference: the intermediary did not get a bad reply — it got no reply in time. The application was working, but for so long that the intermediary stopped waiting.

Typical causes are operations that take a long time by nature, triggered during an ordinary page view: a product import, report generation, a backup run by a plugin, a slow database query on a large number of entries, or an external service — payments, a courier, a warehouse system — that is itself slow to respond. Each of these can work correctly and still cause a 504, because the intermediary has its own time limit, independent of the application.

That is why a 504 is rarely fixed "on the server". It is fixed in the application: long operations are moved into background tasks instead of running while the page is displayed, and slow queries are optimised. Raising the time limit on the intermediary can be a quick workaround, but it only means visitors will stare at a loading page for longer before seeing the same problem.

Cloudflare 52x codes

If your site sits behind Cloudflare — as many sites do, including ours — you will often see codes in the 52x range instead of 502 and 504. These are not codes from the HTTP specification but Cloudflare's own labels, which specify what went wrong between Cloudflare and your server. According to Cloudflare's documentation:

• 520 — the web server returned an unknown error,
• 521 — the web server is down (it refused the connection),
• 522 — the connection timed out,
• 524 — a timeout occurred while waiting for a response.

All four say the same thing as 502 and 504: Cloudflare is working; the problem is behind it, on your server or on the way to it. Contacting Cloudflare support rarely changes anything; contacting your hosting provider usually does.

What Google does with server errors

A short outage will not hurt your search rankings. A long one will, and Google describes the mechanism in its documentation in some detail.

5xx errors — and 429 as well — make Google's crawlers temporarily slow down fetching pages from your server, in proportion to the number of addresses returning an error. Indexed addresses stay in the index, but those that keep returning a server error are eventually removed from it. Once the server responds correctly again, Google gradually returns to its normal pace.

In practice, the most dangerous thing is not a single error but an error nobody knows about: a shop page that has been returning a 500 for a week for one product type, a subpage with a form that stopped working after an update. Such addresses disappear from the results quietly. In Search Console they show up in the page indexing report as server errors — and it is one of the few reports worth checking every week rather than every quarter.

429 Too Many Requests — when the site defends itself

429 is not a 5xx code, but it belongs in the same conversation. The specification defines it as the response to too many requests in a short time — a mechanism for protecting a site against bots, attacks and excessive traffic. As with a 503, the server may send a Retry-After header.

A site owner should know about it for one reason: a firewall that protects the site from bots can also block search engine crawlers. Google treats a 429 as a server error and slows down; if that goes on for long, the consequences are the same as for any persistent error. After switching on new bot protection — at your hosting provider, in your CDN or through a plugin — check in Search Console whether Google's crawler has started receiving refusals.

Who to call — code, location, recipient

An error code does not replace a diagnosis, but it lets you start with the right person.

If an outside company looks after your site, this table is also a test of your contract: is it clear who the recipient is in each row, and how quickly they must respond? How to put that into the agreement is covered in our piece on website maintenance services.

What this article deliberately leaves out

• 404, 403, 401 and 400 errors — these are errors on the request side, with a different diagnosis and a different recipient; we cover them, together with a map of all the codes, in the article on the 404 error.
• 301 and 302 redirects — website migration, where they are at the heart of the whole operation.
• How to spot an error before a customer does — website monitoring.
• Restoring the site when the cause cannot be found — website backup.

The shortest summary: a server error code is an address, not a diagnosis. A 500 sends you to the application and its log, 502 and 504 to the connection between the intermediary and the application, 503 to load or maintenance, 52x to the server behind Cloudflare. And before anyone concludes that "the server is down", it is worth checking whether the error appears everywhere or only for one action — our own 500 was exactly the second kind.