A 503 is the server saying “I cannot handle this request right now” — temporary by definition, but when it is your site and it persists, the diagnosis matters. On WordPress the causes cluster into three groups.
Cause 1: PHP workers exhausted (shared hosting’s classic)
Shared hosting gives your account a small pool of PHP workers (often 1–4). Each uncached page request occupies one until it finishes. A slow plugin, a traffic spike, or a backup job mid-run saturates the pool and every new visitor gets 503.
- Test: does the 503 correlate with a specific activity (backup running, import, crawler burst)? Server error logs show the pileup.
- Fix: end whatever occupies the workers; then make the site cheaper to serve — page caching is the single biggest lever because cached pages barely touch workers. If 503s recur under normal traffic, the hosting tier is simply too small.
Cause 2: Maintenance mode misfiring
WordPress’s maintenance flag (a .maintenance file) can serve 503 headers — the escape hatch is documented in the maintenance-mode guide: delete the file, site returns.
Cause 3: A plugin or loop crashing PHP
A plugin that fatals on every request can produce 503s on some hosts (the fatal handler returns 500 on others — host configuration decides which you see).
- Test: enable WP_DEBUG_LOG (method in the log guide), reload, read the log.
- Fix: deactivate the named plugin — the halving method if the log is ambiguous.
503 during traffic spikes: the real story
If your 503s arrive with marketing emails or social bursts, that is a capacity signal, not a bug. The fix stack in order of impact: aggressive page caching, offloading wp-cron to real cron (visitor-triggered cron multiplies worker load), and ultimately a hosting tier with more workers. We documented the capacity math in the B2B benchmarks — the same thresholds apply to availability, not just speed.
The server cannot serve the request right now — typically PHP workers exhausted, maintenance mode active, or a plugin crashing. It is usually temporary but recurring 503s need diagnosis. Shared hosting's small PHP worker pool saturates: each uncached request occupies a worker. Page caching is the fix that matters — cached pages barely touch workers. Correlate timing with running jobs (backups, imports), check server error logs for the pileup, and read the debug log — the pattern between worker exhaustion and a crashing plugin is distinct. Yes — a plugin that crashes on every request can surface as 503 depending on host configuration. Enable the debug log, reload once, and the log names the file.What does a 503 error mean on WordPress?
Why does my site 503 when traffic spikes?
How do I find what causes 503s?
Can a plugin cause 503 errors?
