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.
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
-
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.
-
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.
-
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.
-
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.
-
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.
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.
-
Diagnosing a slow shop
If the errors come with general slowness, the measurement method.
-
Cron tasks that never run
When a scheduled task saturates the server or never finishes.
-
The database and its indexes
Why a query with no index pushes a page over the timeout.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.