A 502 Bad Gateway or 504 Gateway Timeout usually means one server did not receive a valid or timely response from another server involved in delivering your website. On WordPress, that can involve PHP, the web server, a proxy, CDN, cache layer or upstream hosting service.
Treat 502 and 504 errors as an upstream communication problem first.
Check hosting status, PHP/server logs, resource usage, CDN/proxy status and recent changes. If the error appears only during imports, backups, checkout or admin actions, investigate timeouts and long-running PHP requests.
502 vs 504: what is the difference?
Both errors involve servers talking to one another. A 502 generally means the gateway received an invalid response. A 504 generally means it waited too long for a response. From a business owner’s perspective, both mean the requested page did not complete normally.
Upstream response was invalid or unavailable.
Upstream response took too long.
Resource spikes or upstream instability may be involved.
Long PHP jobs, imports or plugin processes may trigger it.
1. Check whether the host or CDN has an outage
If every page suddenly fails at once, check your hosting provider, CDN and DNS service status before changing WordPress. An infrastructure outage cannot be fixed by reinstalling plugins.
2. Check PHP and web-server logs
Look at the exact timestamp of the error. PHP fatal errors, upstream connection failures and resource exhaustion may be visible in logs even when the browser only shows a generic gateway page.
3. Look for resource spikes
CPU, memory, concurrent processes or PHP workers can become saturated. A traffic spike, backup, import, scheduled task, bot attack or inefficient plugin can consume the resources needed to answer normal requests.
If the problem appears at the same time every day, check scheduled backups, cron jobs and WooCommerce actions.
4. Check recent plugin, cache and server changes
If the error began after enabling object cache, changing CDN settings, updating PHP or installing a plugin, use that timing as a clue. Do not undo unrelated settings across the whole site.
5. Test a direct origin request where appropriate
When a CDN or reverse proxy sits in front of the site, the public error may come from that layer rather than WordPress. Your host or developer can compare requests through the proxy with requests to the origin server to see where the chain is breaking.
Host/CDN outage?
What timed out or failed?
CPU, memory, workers?
Traffic, cron, update or import?
What if the error only appears in WordPress Admin?
That often suggests a long-running admin request, plugin process, import, page-builder save or API request rather than a site-wide outage. Compare the failing action with ordinary front-end page loads.
What if checkout gets a 502 or 504?
Treat it as urgent. A customer may see an error after clicking Pay while the payment gateway has already processed part of the transaction. Check the WooCommerce order and payment gateway before asking the customer to retry.
For broader website failures, see our website troubleshooting guide. If the problem follows an update, see WordPress broke after an update.
For a live outage, use our emergency website fixes service. For ongoing uptime, resource and website checks, see website maintenance and support.
502 and 504 errors point to different stages of the request
Both errors normally mean a gateway or proxy could not get the response it expected from an upstream service, but the timing matters. A 502 often appears when the upstream response is invalid or the application process has crashed. A 504 more often means the gateway waited too long. On WordPress that can involve PHP workers, database queries, external APIs, backups, cron jobs, imports or a traffic spike.
Check hosting health, PHP processes, database and origin availability.
Look for a slow query, API call, import, checkout or admin request.
Compare the CDN/proxy response with a direct origin test.
Check scheduled backups, scans, cron and resource-heavy jobs.
Do not keep refreshing a struggling server
Repeated retries can add load while the origin is already short of workers or memory. Capture the exact time, URL and action, then inspect server and PHP logs around that moment. If a recent deployment or plugin update lines up with the first errors, reproduce the problem on staging rather than repeatedly testing the live checkout or lead page.
502 vs 504: high-intent causes to check
Searchers commonly want to know whether the fault is the host, WordPress, Cloudflare/CDN, PHP workers or one slow plugin. A 502 means a gateway received an invalid upstream response; a 504 means it waited too long. The browser message is only the final symptom.
PHP-FPM workers and resource saturation
Check CPU, RAM, process limits and PHP worker usage around the exact incident. A backup, import, cron job or traffic spike can exhaust workers while the server itself remains online.
CDN or reverse-proxy timeouts
If a proxy such as Cloudflare sits in front of the origin, compare the public request with an origin request where your host can do so safely. That helps determine whether the timeout is occurring at the edge, proxy-to-origin connection or PHP application layer.
External APIs and long-running requests
Payment gateways, feeds, remote APIs and slow database queries can keep a PHP request open until an upstream timeout is hit. Look for action-specific patterns rather than simply increasing every timeout value.
Scheduled actions
If the error repeats at predictable times, inspect WordPress cron, WooCommerce scheduled actions, backups and security scans. Recurring timing is valuable evidence.
Competitor gap: distinguish capacity from bad code
More server resources can hide a slow request without fixing it. Compare logs, request timing and resource graphs to establish whether the server is genuinely undersized or one process is misbehaving.
FAQ
Is a 504 always the hosting company’s fault?
No. Hosting capacity can be involved, but slow PHP code, plugins, external APIs and long-running requests can also trigger timeouts.
Can a CDN cause 502 errors?
A CDN or proxy can return a 502 when it cannot get a valid response from the origin server or when its own upstream path has a problem.
Should I increase timeout limits?
Only after finding what is taking too long. Increasing a limit can hide inefficient code without solving the underlying cause.