A 503 Service Temporarily Unavailable means Nginx could not fulfill the request because the upstream service it depends on is unavailable or overloaded. Unlike a 504, which is a timeout, a 503 is an immediate refusal – the upstream is not slow, it is simply not accepting requests right now.
The error is temporary by nature. The server is operational, Nginx is running, but something behind Nginx is not available at that moment.
What causes a 503
PHP-FPM pool exhaustion
This is the most common cause on WordPress hosting. PHP-FPM maintains a pool of worker processes. Each incoming request that requires PHP occupies one worker until the request completes. The pool has a configured maximum.
When all workers are busy and a new request arrives, it joins a queue. If the queue is also full, Nginx gets an immediate rejection from PHP-FPM and returns a 503 to the visitor.
This happens when:
- A traffic spike brings in more concurrent requests than the pool can handle
- A bot or crawler is hammering PHP endpoints and consuming workers
- Pages are slow to generate, keeping workers occupied longer than usual
- A long-running process is tying up workers that should be serving requests
The key difference from a 504: with pool exhaustion the connection is refused immediately rather than timing out. Nginx knows right away that PHP-FPM cannot take the request.
PHP-FPM is down or crashed
If the PHP-FPM process itself has crashed or failed to start, Nginx cannot connect to it at all. Every PHP request returns a 503 until PHP-FPM is restarted.
Common reasons PHP-FPM crashes:
- A fatal error in a PHP script during startup
- A misconfigured pool configuration
- The process running out of memory
- A server restart where PHP-FPM did not come back up cleanly
Rate limiting
Nginx can be configured to rate limit requests per IP. If a visitor or bot exceeds the configured rate, Nginx returns a 503 (or 429, depending on configuration) rather than passing the request upstream. This is intentional behavior, not an error in the traditional sense.
Upstream server unavailable
If Nginx is configured as a reverse proxy and the upstream application server is down, restarting, or refusing connections, Nginx returns a 503 to the client. This applies to Node.js applications, Python apps, or any other backend Nginx proxies to.
Maintenance mode
Some WordPress maintenance mode plugins return a 503 status code intentionally to signal to search engines that the site is temporarily unavailable. If you recently enabled maintenance mode, this is expected behavior.
How to diagnose a 503
Check the Nginx error log
The error log is the first place to look. A 503 caused by PHP-FPM pool exhaustion typically shows:
connect() to unix:/run/php-fpm/www.sock failed (11: Resource temporarily unavailable)or
no live upstreams while connecting to upstreamA 503 caused by PHP-FPM being completely down shows:
connect() to unix:/run/php-fpm/www.sock failed (2: No such file or directory)The socket path in your logs may differ from the examples above, but the pattern is the same.
Determine whether it is site-wide or isolated
If every page on the site returns a 503, the problem is at the server level – PHP-FPM is down, or the pool is completely exhausted. If only specific pages are affected, the problem may be more isolated.
Check whether it correlates with traffic
If the 503 appears during traffic spikes and clears on its own when traffic drops, pool exhaustion is the likely cause. Check your access logs for request volume around the time of the error.
Check for bot traffic
High bot volume consuming PHP workers is a frequent cause of 503 on shared hosting. Check your access logs for repeated requests from the same IP or user agent, particularly to PHP endpoints like wp-login.php, xmlrpc.php, or wp-cron.php.
How to fix a 503
If PHP-FPM pool is exhausted
The immediate fix is reducing the load on the pool. Longer term, the options are increasing the pool size (requires server configuration access) or reducing how much work each request does.
At the application level:
Enable full-page caching. A cached page is served by Nginx directly without touching PHP at all. Fewer requests reach PHP-FPM, which means more workers available for requests that genuinely need PHP. Use a caching plugin like WP Rocket, W3 Total Cache, or LiteSpeed Cache.
Identify and stop bot traffic. Bots hitting PHP endpoints consume workers without generating any legitimate value. Check your access logs for non-human traffic patterns and block them at the server level if possible.
Reduce PHP execution time. Slow pages hold workers longer. Identify slow pages using Query Monitor and optimize database queries, reduce plugin overhead, and eliminate unnecessary external HTTP calls during page generation.
Disable wp-cron.php web requests. WordPress’s built-in cron system triggers on page loads by default. Under traffic, this adds extra PHP executions. Replace it with a real system cron:
Add to wp-config.php:
php
define( 'DISABLE_WP_CRON', true );Then add a system cron job that runs WP-CLI instead:
*/5 * * * * wp --path=/path/to/wordpress cron event run --due-nowDisable xmlrpc.php if not in use. xmlrpc.php receives automated requests constantly and each one occupies a PHP worker. If you are not using remote publishing or a mobile app that requires it, disable it.
If PHP-FPM has crashed
PHP-FPM needs to be restarted. On managed hosting, contact your provider. The error log will show what caused the crash – a configuration error, an out-of-memory event, or a startup failure.
If PHP-FPM is crashing repeatedly, the underlying cause needs to be fixed rather than just restarting the process. Check the PHP error log for fatal errors that may be triggering the crash.
If a specific plugin is causing the issue
Some plugins make external HTTP requests, run heavy database operations, or consume significant memory during initialization. If the 503 started after installing or updating a plugin, disable that plugin and test.
Use the WordPress health check plugin or access the site with a plugin debugging parameter to isolate which plugin is responsible.
If you are in maintenance mode
If you intentionally put the site in maintenance mode, this is expected. Disable maintenance mode when your work is complete. If you did not intentionally enable it, check whether a plugin update left a .maintenance file in the WordPress root directory. Deleting that file clears maintenance mode.
The difference between 503 and 504
These two errors are related but distinct:
A 503 means the upstream refused the connection or is not available. Nginx got an immediate response saying “I cannot take this request right now.” The failure is fast.
A 504 means the upstream accepted the connection but did not respond in time. Nginx waited for the configured timeout and gave up. The failure is slow.
Pool exhaustion can produce either error depending on how PHP-FPM is configured to handle a full queue – it can reject immediately (503) or queue and eventually time out (504).
What to tell your hosting provider
If the 503 persists and you cannot resolve it at the application level, contact your provider with:
- When the error started
- Whether it is affecting all pages or specific ones
- Whether it correlates with a specific action, plugin update, or traffic event
- The relevant lines from your Nginx error log
For pool exhaustion on a site with legitimate traffic growth, a plan upgrade or pool size adjustment may be necessary.
Summary
A 503 in Nginx means the upstream service – usually PHP-FPM – is unavailable or refusing connections. The most common cause on WordPress hosting is PHP-FPM pool exhaustion, where all available PHP workers are occupied and new requests are being rejected. Less common causes include PHP-FPM crashing, rate limiting, or intentional maintenance mode.
Diagnose by checking the Nginx error log for connection refusal messages and correlating the error with traffic patterns or recent changes. Fix by reducing load on PHP-FPM through caching, bot blocking, and plugin optimization. If PHP-FPM is down entirely, it needs to be restarted and the cause of the crash investigated.