You open your site and get a plain white page: 503 Service Unavailable.
Good news: your server is alive. It’s answering, but refusing the work for now, usually because it’s overloaded, rate-limiting you or stuck in maintenance mode. The error page and one log line tell you which, and each has its own fix.
We made Nginx throw a 503 error five ways to see the clues each leaves. The cause most guides blame first didn’t produce a 503 at all.
What does 503 Service Unavailable mean?
A 503 Service Unavailable means the server can’t handle your request right now because of a temporary overload or planned maintenance. The HTTP standard, RFC 9110, expects the problem to pass after a delay.
The key words are right now. A 503 is a deliberate refusal, not a crash.
- The server is up. It accepted your connection and sent a proper reply, which a dead server can’t do.
- It chose to say no. A rate limit, a full queue or a maintenance switch turned you away before any real work started.
- It may tell you when to come back. The optional
Retry-Afterheader gives a wait in seconds. WordPress sends 600, which is ten minutes.
So don’t ask whether the server is broken. Ask which part of it said no.
Getting a 503 on a site you don’t own?
The fix is on their side, but how you retry still matters.
- Wait, then reload once. A 503 from a spike or a plugin update usually clears within minutes.
- Stop mashing refresh. If a rate limit caused it, every extra click counts against you. In our test, 9 of 10 rapid requests from one address were refused.
- Try another network. Rate limits usually count per IP address. On office Wi-Fi, a VPN or mobile data, strangers share your address and may have used up the allowance.
Clearing your browser cache won’t help. The refusal happens on the server.
We forced Nginx to send a 503, five different ways
Our setup, in November 2026: Nginx 1.26.3 on a Linux test box, a tiny Python app behind it, and a script firing requests until something refused.
This was a lab, not your WordPress server. Still, a production Nginx returns the same codes and writes the same log lines.
| What we did | What came back | How fast |
|---|---|---|
| 10 requests at once, rate limit of 2 per second | 1 page, 9 × 503 | Under 1 ms each |
| Same, with burst=5 nodelay added | 6 pages, 4 × 503 | Under 1 ms each |
| 5 requests at once, 1 connection allowed per IP | 1 page, 4 × 503 | Under 1 ms each |
| App with 2 workers and 2 queue slots, 8 requests | 4 pages, 4 × 503 | Pages in 2 s and 4 s; 503s in 2 ms |
| App in WordPress-style maintenance | 503 with Retry-After: 600 | Instant |
| Both app servers switched off | 502 Bad Gateway, not 503 | Under 1 ms |
Three findings changed how we’d debug this.
The page title tells you who said no. When Nginx itself refused, the page read 503 Service Temporarily Unavailable. When the app refused, Nginx passed the app’s own reply through untouched: 503 Service Unavailable, with the app’s text and its Retry-After header intact.
A 503 arrives fast. Every refusal came back in a couple of milliseconds, because the server never started the work. If you waited 30 or 60 seconds before the error, you’re probably looking at a timeout, not a refusal.
Dead app servers gave us a 502. Plenty of guides list “backend down” as a 503 cause. With every upstream server off, Nginx logged no live upstreams and returned a 502.
Apache is the exception. Its mod_proxy is known to answer 503 when it can’t reach the backend, though we didn’t test Apache ourselves.
These are the log lines Nginx wrote for each refusal:
[error] limiting requests, excess: 0.998 by zone "perip", client: 127.0.0.1,
request: "GET /ratelimit/ HTTP/1.1"
[error] limiting connections by zone "conns", client: 127.0.0.1,
request: "GET /connlimit/?sleep=3 HTTP/1.1"
[error] no live upstreams while connecting to upstream (this one was a 502)What causes a 503 Service Unavailable on WordPress?
On a WordPress site, nearly every 503 comes from one of five places. Here’s how to spot each and what to do.
1. Maintenance mode from an update
When WordPress updates a plugin, theme or core, it drops a file called .maintenance in the site’s root folder. While that file exists, every visitor gets a 503 with the message “Briefly unavailable for scheduled maintenance. Check back in a minute.”
Here’s what most fix-it guides miss. In the current WordPress source, the lock expires by itself. If the timestamp inside .maintenance is over 10 minutes old, WordPress ignores the file.
So a message that’s still there after ten minutes has another cause too.
Delete the file anyway, then check what else is going on:
cd ~/public_html # your WordPress root
ls -la .maintenance && rm .maintenance
ls wp-content/maintenance.php 2>/dev/null # a custom maintenance page, if anyStill seeing the 503? Look for a coming-soon or maintenance plugin that’s switched on. Then re-run any update that stopped halfway, so the plugin isn’t left with missing files.
Real-world tip: update plugins one or two at a time, and try big updates on a copy of the site first. Our roundup of WordPress staging tools covers free ways to do that.
2. A rate limit or firewall that’s too strict
Rate limits protect your server from floods, but a tight one locks out real people. Nginx’s limit_req and limit_conn both answer 503 by default, so a limit looks exactly like an overload.
Search the error log for limiting requests or limiting connections. Seeing them at normal traffic means the limit is too low. A small burst allowance fixes most cases: in our lab, burst=5 nodelay took us from 1 page in 10 to 6.
We’d also change the status code. With limit_req_status 429; our rejected requests returned 429 Too Many Requests, so you can tell a limit from an overload at a glance.
Security plugins and host firewalls do the same job further up. If only wp-login.php or xmlrpc.php fails, suspect a brute-force rule. Our list of WordPress security plugins shows where those settings live.
3. No free PHP workers
Each uncached WordPress page needs a PHP worker, and your plan has a fixed number. When all of them are busy, new requests wait or get turned away.
Our two-worker test app showed the pattern. Two requests got pages in 2 seconds. Two waited in the queue and got theirs in 4. The other four were refused in 2 milliseconds.
Real PHP-FPM behind Nginx is a bit different. It queues extra requests instead of refusing them, so a full pool often ends in a slow page or a 504. The 503s come from a host or app layer that caps the queue.
Either way, the PHP-FPM log will show this line:
WARNING: [pool www] server reached pm.max_children setting (5), consider raising itThe cheapest fix is to keep visitors away from PHP. A cached page comes straight from disk and never uses a worker. A caching plugin like WP Rocket handles that, and our checklist to speed up WordPress covers the rest.
4. Your hosting plan hit its limit
Shared hosts cap CPU, memory and simultaneous processes for each account. Cross that line during a sale, a viral post or a bot crawl, and the host’s front server answers for you.
You’ll get a 503 or the host’s own branded error page.
WordPress can’t see those limits. Your host’s control panel usually shows resource usage, and support can tell you which limit you hit. If the answer is “every busy afternoon”, you’ve outgrown the plan.
5. A CDN or proxy in front of your site
Behind Cloudflare, read the error page’s text first. Cloudflare’s docs say a 503 page that mentions cloudflare came from their network. One that doesn’t came from your server, so work through causes 1 to 4.
Cloudflare Workers that run out of CPU time or memory return 503s too. And 503s that appear only in analytics are Speed Brain prefetches that visitors never see.
How to find which layer sent the 503
Five minutes with a terminal usually names the culprit. Go in this order.
Trace a 503 to its source
Stop at the first step that gives you an answer.
-
Step 1 of 5
Read the headers and the page title
Run curl -sI on the failing URL. Retry-After: 600 points to WordPress maintenance. Service Temporarily Unavailable points to Nginx itself. The word cloudflare points to Cloudflare.
-
Step 2 of 5
Search the web server's error log
The phrases limiting requests or limiting connections prove a limit fired. Each line names the URL and the client IP.
-
Step 3 of 5
Check the WordPress root for .maintenance
If the file exists and the 503 started during an update, delete it and finish the update.
-
Step 4 of 5
Check the PHP-FPM log and the server load
A max_children warning or a pinned CPU means you’re out of workers or out of server. Cache more, then talk to your host.
-
Step 5 of 5
Ask your host what they blocked
Nothing above? Then the 503 came from a layer you can’t see. Send support the exact time and URL.
curl -sI https://example.com/ | grep -iE '^HTTP|retry-after|server'
sudo grep -E 'limiting (requests|connections)' /var/log/nginx/error.log | tail -n 20
sudo grep 'max_children' /var/log/php*-fpm.log | tail -n 5503 vs 502 vs 504: same family, different problem
All three are server-side errors. Each points to a different weak link.
| Error | What the server is saying | Speed in our labs | Check first |
|---|---|---|---|
| 503 Service Unavailable | I’m up, but not taking this request now | Instant | Maintenance file, rate limits, worker pool |
| 502 Bad Gateway | The app behind me failed or sent garbage | Instant | Is PHP-FPM or the app running? |
| 504 Gateway Timeout | The app behind me took too long | After the full timeout | Slow queries and outside API calls |
Our 502 Bad Gateway guide shows a crashed app in the logs. The 504 Gateway Timeout guide times when Nginx gives up waiting.
Will a 503 hurt your Google rankings?
A short 503 won’t. A 503 that lasts for days can cost you pages.
Google’s crawler documentation says 5xx errors and 429s make Googlebot slow down for a while. Indexed pages stay put at first, and crawling speeds back up once your server returns 200s. URLs that keep failing are eventually dropped.
That makes 503 the right code for planned downtime. A maintenance page served with 200 tells Google your homepage now says “back soon”, and a 404 says the page is gone. A 503 with Retry-After tells the truth: come back later.
Our take: keep planned 503s to hours, not days, and never leave a coming-soon plugin running on a live site. If Search Console’s crawl stats show server errors on days you didn’t plan downtime, treat it as a hosting problem, not an SEO one.
When 503s keep coming back
An occasional 503 during an update is normal. Several a week at busy times means the server is too small for your traffic.
Cache first, because it costs least. Then compare plans: our managed vs shared WordPress hosting breakdown shows what the extra money buys.
On a budget, a bigger Hostinger plan buys headroom. Ask its support how many PHP workers each tier gets before you pick. If you’d rather hand server tuning to someone else, a managed WordPress host like Pressable takes it off your plate.
Disclosure: we may earn a commission if you buy through our Hostinger, Pressable or WP Rocket links. Your price doesn’t change.
Frequently Asked Questions
How long does a 503 Service Unavailable error last?
Usually minutes. A rate-limit block lifts once requests slow down, and a WordPress update lock expires after ten minutes. A 503 caused by a plan limit lasts as long as the traffic does, and a forgotten maintenance plugin lasts until someone switches it off.
Can a WordPress plugin cause a 503 error?
Yes, in two ways. Coming-soon and maintenance plugins send 503s on purpose until you turn them off. A heavy plugin can also hold PHP workers on every page, so the server runs out of room at far lower traffic.
Why do I get a 503 only on wp-login.php or wp-admin?
A login rate limit is the usual reason. Hosts, firewalls and security plugins limit wp-login.php and xmlrpc.php hard because bots attack them. Wait a few minutes, use a single tab, and ask your host to allow your IP address if it keeps happening.
What does HTTP Error 503. The service is unavailable mean on IIS?
On a Windows server running IIS, that exact message usually means the site’s application pool has stopped. Rapid crashes can make IIS disable the pool automatically. The site owner needs to check the event log and restart the pool, so visitors can only wait.
Does a 503 mean my site is under attack?
Not usually. Updates, traffic spikes and tight limits cause far more 503s than attacks. Check your access log anyway. If a few IP addresses or one user agent make most of the requests, it’s a bot flood, and a firewall rule beats a bigger plan.
Should I restart the server to fix a 503?
Only as a last resort. A rate limit or update lock clears on its own, and a restart wipes the evidence of what filled your worker pool. Read the error log and the PHP-FPM log first, then restart if a stuck process is the cause.
How long can a site return 503 before Google drops pages?
Google doesn’t publish a number. Its documentation says pages stay indexed at first and are eventually dropped if errors persist. Treat a few hours as safe and several days as risky, and fix repeat 503s on important URLs first.
Is a 503 error the same as a 500 error?
No. A 500 Internal Server Error means the code crashed while building the page, often a PHP fatal error. A 503 means the server refused to start the work at all, so the fix is about capacity or maintenance, not broken code.
The bottom line
A 503 Service Unavailable error means your server is working but turned the request away. Visitors should wait, retry once and try another network if a rate limit is to blame.
Site owners should read the page title and headers, then the error log. Together they say whether it’s a WordPress update lock, a tight limit, a full PHP worker pool or a host cap. Fix that one cause, and don’t assume the app crashed: in our lab, dead apps produced 502s.
Next step: save the three trace commands above somewhere handy. Most 503s are over in minutes, and the evidence goes with them.
