# 502, 503, 504: the server gives up mid-request

> Unlike a 500 error, these three codes almost never come from your site’s code. They are issued by the layer sitting in front of it — load balancer, cache, host proxy — which waited for an answer and eventually gave up. Knowing which one gave up, and after how long, leads straight to the cause.

- Source canonique : [https://allaux.fr/en/problemes/erreur-504-et-delais-depasses](https://allaux.fr/en/problemes/erreur-504-et-delais-depasses)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Time it: note after how many seconds the error appears, 30, 60 or 300. That number matches a configured limit, never chance. Compare it with max_execution_time on the PHP side and with the proxy timeout in the hosting panel. A 502 is different: the PHP-FPM process died, and its trace sits in error_log at the same timestamp.

## What each code means

502: the intermediary reached the application service, but it returned an invalid response or ended abruptly. Typically, the process running PHP was killed mid-execution, out of memory or by the host’s resource manager.

503: the service is unavailable or refusing new requests. This is the code of a stopped service, a full queue, or an active maintenance mode. It is also what a CMS deliberately returns during an update.

504: the intermediary did pass the request on, but no answer arrived within the allowed time. The site is still working when the connection is cut. This is the code of an operation that is too long, not an impossible one.

## Isolating the operation that takes too long

1. **Time the failure** — Note how many seconds pass before the error appears. A round, always identical figure — 30, 60, 120, 300 — is a configured limit, not chance. That figure often identifies the component doing the cutting.
2. **Identify the affected pages** — One admin page, an export, an import, a search: the error almost always follows one specific heavy operation, not the whole site.
3. **Check whether the work happens anyway** — An import that returns a 504 but whose products still appear in the database means processing continued server-side. Running it again then duplicates the data.
4. **Look at scheduled tasks** — A heavy automated task firing at a fixed hour can saturate the server and cause 502s or 504s on public pages for its duration.
5. **Ask for the limits in force** — Maximum execution time, allocated memory, number of simultaneous processes: those three values set the threshold, and the host will state them.

## Raising the timeout is not always the right answer

> Moving a limit from 30 to 300 seconds makes the message disappear, but leaves a page that takes five minutes to answer — and holds a server process for all that time. On a repeated operation, that manufactures the very saturation you were avoiding. The right answer is more often to split the work into batches.

## The causes I meet most

A catalogue import or export run in one block across several thousand rows.

An admin page listing every record with no real pagination, on a table that has grown for years.

A call to an external service — carrier, business software, supplier — that no longer answers, whose wait blocks the whole page.

A traffic spike on shared hosting, where the number of simultaneous processes is capped.

A database query with no suitable index, scanning a whole table on every display.

## Carry on with the right page

- **Choosing e-commerce hosting** — Which limits to look at when resources really are the problem. ([/guides/choisir-hebergement-ecommerce](/guides/choisir-hebergement-ecommerce))
- **Diagnosing a slow shop** — If the errors come with general slowness, the measurement method. ([/guides/diagnostiquer-boutique-lente](/guides/diagnostiquer-boutique-lente))
- **Cron tasks that never run** — When a scheduled task saturates the server or never finishes. ([/prestashop/problemes/taches-cron-ne-sexecutent-pas](/prestashop/problemes/taches-cron-ne-sexecutent-pas))
- **The database and its indexes** — Why a query with no index pushes a page over the timeout. ([/glossaire/base-de-donnees](/glossaire/base-de-donnees))

## FAQ

### Is a 504 error my host’s problem?

Not necessarily. The host issues the message, but it is your site that failed to answer in time. The useful question is which operation takes that long, and why.

### Why does the error only appear on one page?

Because that page triggers an operation the others do not. That is excellent news for the diagnosis: the search is already narrowed to a few processes.

### Is a 503 during an update normal?

Yes, temporarily. A 503 that persists after the update finished means the maintenance file was not removed, which takes seconds to fix with file access.

### Can these errors come from an attack?

An abnormal volume of automated requests saturates the available processes and produces exactly these codes. Access logs distinguish a legitimate traffic spike from automated scanning.

### Should I move to a dedicated server?

Only if measurement shows the limits are genuinely reached by normal use. On badly batched processing, a bigger server pushes the threshold back by a few months, no more.
