Fixing 502, 503 and 504 errors in WordPress

502, 503 and 504 errors look alarming, but they have something useful in common. They all mean one part of your hosting setup couldn't get a proper answer from another part in time. Unlike a 500 internal server error, which usually means WordPress itself crashed, these errors often happen before WordPress gets a chance to run at all.

Most WordPress sites have at least two layers handling each request. A web server (Nginx, Apache or LiteSpeed) receives the visit and passes it to PHP, which runs WordPress. Many sites also sit behind a CDN or proxy such as Cloudflare. When one layer passes a request to the next and gets no response, a broken response or a "too busy" response, you see one of these errors.

• 502 Bad Gateway means the layer in front received an invalid response, or none at all. PHP may have crashed or restarted, or Cloudflare couldn't get a proper response from your server.
• 503 Service Unavailable means the server is temporarily refusing requests. It's overloaded, out of PHP workers, being rate limited by your host or deliberately in maintenance mode.
• 504 Gateway Timeout means the layer in front gave up waiting. PHP was still working on the request when the time limit ran out.

If your whole site is down and you're not sure which error you're dealing with, start with our guide to diagnosing a WordPress site that's down.

Work out where the error is coming from

The error page itself often tells you which layer produced it.

If your site uses Cloudflare and you see a Cloudflare-branded 502 or 504 page, Cloudflare reached your server but your server returned the error. The problem is at your host, not Cloudflare.¹ Cloudflare's own timeout error is 524, which means your server accepted the connection but didn't send a response before Cloudflare's time limit (125 seconds by default).² Treat a 524 the same way as a 504 below.

A plain page reading "502 Bad Gateway" with "nginx" underneath, or a branded page from your host, came from the server. A WordPress-styled page saying "Briefly unavailable for scheduled maintenance" is a 503 generated by WordPress during updates, and has its own fix.

Also note whether the error affects the whole site, only the admin area or only certain pages. An error on one slow page (a big product search, an export, an import) points at that task. An error everywhere points at the server or at traffic.

Check your host and try again

These errors are often temporary. A PHP restart during a server update or a brief spike in load can cause a few minutes of 502s that clear up by themselves.

Wait a couple of minutes and reload. Check your host's status page or support channels for incidents. If you use Cloudflare, you can pause it temporarily from the domain's Overview page (Advanced Actions → Pause Cloudflare on Site) to see whether the site loads directly from the server.³ Pausing also switches off Cloudflare's firewall and SSL for the domain, so turn it back on as soon as you've finished testing.

If the error is persistent, or keeps coming back at busy times, keep going.

Look for a traffic spike

A sudden flood of requests is one of the most common causes of 503 and 504 errors on small and mid-sized sites. It usually isn't customers. Aggressive crawlers, AI scrapers, vulnerability scanners and login brute-force attempts can each send thousands of requests an hour, and every uncached request needs PHP.

Your hosting control panel will usually have traffic or access log statistics. Look for:

• Large numbers of requests to wp-login.php or xmlrpc.php
• A single IP address or small range making most of the requests
• Bots with names you don't recognise crawling every page, search result or product filter combination
• Heavy traffic to WooCommerce URLs with ?add-to-cart= or filter parameters, which can't be cached

If you find the source, block it at the firewall level (your host, Cloudflare or a security plugin) rather than inside WordPress, so the requests never reach PHP. If you use Cloudflare, its bot management and rate limiting rules are worth enabling. Disabling XML-RPC if you don't use it closes off one common target, and our guide to dealing with WordPress spam covers login and form abuse. If the traffic looks like attacks on a particular plugin, check whether that plugin has a known security vulnerability.

Check PHP workers and resource limits

Your hosting plan allows a fixed number of PHP processes (often called workers or children) to run at once. Each uncached page view, admin screen, AJAX request and cron job needs one. When they're all busy, new requests queue up, and if the queue gets too long you'll see 502s, 503s or 504s.

Shared hosting plans often have tight limits on workers, CPU, memory and simultaneous connections. If you're hitting them, your control panel may show resource usage graphs with spikes that line up with the errors. Hosts using CloudLinux show a "508 Resource Limit Is Reached" error when an account runs out of its allowance of simultaneous processes, which is the same underlying problem.⁴ Database connection limits work in a similar way, and can show up as a database connection error instead.

There are two ways to fix this. Reduce the number of requests that need PHP (better caching, blocking bots, fixing slow plugins), or increase the resources available (upgrading your plan or moving to a host with more generous limits). It's usually worth doing the first before paying for the second.

Find slow requests causing timeouts

A 504 on a particular task means that task takes longer than the server allows. Common culprits include:

• Imports and exports of large product or user lists
• Backup plugins running inside WordPress rather than at server level
• Page builders rendering very large pages
• Plugins calling slow external services (shipping rate APIs, social feeds, licence checks) without a sensible timeout
• Slow database queries, often from bloated tables or missing indexes

The Query Monitor plugin can show which queries and HTTP API calls are slow on a given page. Your host's PHP slow log, if they offer one, shows which scripts are taking longest.

Raising timeouts can help with a genuine one-off task such as a big import, but it's rarely the right fix for a page visitors see. A page that takes 60 seconds to generate will fall over under any real traffic. Our guides to diagnosing a suddenly slow WordPress site and fixing a slow admin dashboard cover finding and fixing slow queries and plugins.

Check for crashing PHP processes

Persistent 502 errors, especially on specific pages, can mean PHP is crashing partway through a request rather than returning an error. Common causes are running out of memory, a buggy PHP extension or a plugin that isn't compatible with your PHP version.

Check your server's PHP error log (usually available in your hosting control panel) for entries around the time of the error. Lines mentioning "segmentation fault", "SIGSEGV", "child exited" or "Allowed memory size exhausted" point at the cause. If you've recently updated a plugin or changed PHP version, that change is the first thing to roll back. Our guide to recovering from a broken update explains how to do that safely.

Check WP-Cron and background tasks

WordPress runs scheduled tasks through WP-Cron, which triggers on normal page visits. On a busy site, or one with lots of scheduled work (WooCommerce, backups, newsletters, sitemaps), cron can pile up and take workers away from visitors.

If errors happen at regular intervals or coincide with backups and scheduled imports, try moving WP-Cron to a real server cron job. Download a copy of wp-config.php first, since a typo in that file can take the whole site offline. Then add this line:⁵

define( 'DISABLE_WP_CRON', true );

Then set up a server cron job in your hosting control panel that runs every five minutes. Without that server cron job, scheduled tasks stop running completely, so set it up straight away. Our guide to fixing scheduled posts that fail to publish walks through the setup. If you run WooCommerce, also check for a backlog of past-due scheduled actions.

Make sure caching is doing its job

Good page caching is the best defence against these errors, because cached pages are served without PHP. Check that your caching plugin or host cache is actually active and serving pages. Many caching plugins add a comment at the bottom of the page source, or a response header, showing whether the page was cached.

Logged-in users, WooCommerce carts and checkouts can't be fully page cached, so a busy store needs more headroom than a brochure site with the same traffic. An object cache such as Redis, if your host offers it, reduces database load for those uncached requests. Our guide to a WordPress site not updating explains how the different caching layers fit together.

Still seeing errors?

If the errors continue after ruling out traffic, slow requests and resource limits, your host is the next step. Ask them for the relevant entries from the web server and PHP-FPM error logs at the times you saw errors, and whether your account hit any resource limits. If you need help reading the logs or deciding whether it's time to move host, my WordPress development service and emergency WordPress support cover server errors, performance problems and hosting migrations.