A 502 or 504 means one server was waiting on another and stopped waiting. Something upstream — PHP, the database, or a proxy — did not answer in time. These are the hardest errors to self-diagnose because the message tells you nothing about which layer failed, and the answer is almost always in logs you cannot see from wp-admin.
Before you buy, one quick look
Read-only, and it can save you the purchase.
Check your host’s status page for a reported incident, and if you have other sites on the same account, load one of them.
Other sites are also failing — it is the host. Contact them first; this fix cannot help until their infrastructure is back.
Only this site — it is something on the site holding a request open too long. That is what this diagnoses.
HTTP 502 / 504 gateway timeout diagnosis
The server accepts the request then gives up waiting for a response. We work out which layer is timing out, fix what we can reach, and give you the evidence for your host if it is theirs.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| 502 or 504 after a long pause | This fix covers it |
| Immediate 500 with no delay | HTTP 500 internal server error |
| PHP error naming a time limit | Maximum execution time exceeded |
| Only under traffic spikes | This fix covers it |
| All sites on the account are down | A host incident — contact them first |
What you are seeing
- A 502 or 504 page after a noticeable delay, not immediately
- It may be intermittent — reloading sometimes works
- It may correlate with traffic, or with a scheduled task running
- The admin may be affected while the front end is cached and fine
Common causes
- A PHP process taking longer than the proxy will wait
- The database blocked or overloaded, holding requests open
- A slow external API call inside a page render
- PHP worker processes exhausted, so new requests queue and expire
- A misconfigured proxy or CDN timeout shorter than the origin needs
What we do
- Take a full backup before touching anything
- Read the server, PHP and proxy logs to identify which layer is timing out
- Correlate failures against traffic and scheduled tasks
- Fix what sits at the WordPress layer — slow queries, blocking calls, stuck cron
- Adjust timeouts and worker configuration where we have access
- Load-test to confirm the failures stop under the same conditions
What is included
- A diagnosis naming the layer that was timing out, with evidence
- Fixes applied to anything within the WordPress layer
- A support ticket written for your host, with logs attached, if it is theirs
- The pre-fix backup, kept for 30 days
Not included
- Fixing infrastructure on a host we cannot access
- Upgrading your hosting plan, though we say if that is the honest answer
- Migrating you to a different host, which we quote separately
- Malware removal, design changes or content work
Questions about this fix
My host says it is my site. Is that true?
Sometimes, and sometimes it is a way of closing the ticket. We read the logs and find out which layer actually timed out. If the evidence points at their infrastructure, you get a written ticket with the logs attached, which is much harder to deflect.
It only happens at busy times. Does that change the diagnosis?
It usually confirms it. Load-related timeouts point at worker exhaustion or database contention rather than a broken file. That is a capacity and efficiency problem, and it is fixable without a bigger plan more often than hosts suggest.
Reloading fixes it. Should I worry?
Yes. Intermittent timeouts are early warning — the site is close to a limit and crossing it occasionally. Traffic growth or a slow day at your host will turn occasional into constant.
Could a plugin cause a 504?
Easily. Any plugin that calls an external service during a page render will hang the whole request when that service is slow. It is one of the most common causes we find, and one of the easiest to fix once identified.
Is this the same as a slow connection on my end, like weak WiFi?
No — this happens on the server side, between your hosting and whatever it's waiting on, before the response ever reaches your browser. Your own connection speed has nothing to do with it.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.