Give your WordPress site its first task.
Connect the site you already have, add your agent to Slack or Telegram, and tell it what you need.
Connect your siteStart with 500 free credits. No credit card needed.
On this page
- What does a 503 response code actually say?
- How do you read the 503 instead of the error page?
- Which part of a WordPress site sent the 503?
- How is a 503 different from a 500, 502, 504 or 429?
- When is it safe to retry a 503?
- When should your site return a 503 on purpose?
- What should you do with an unplanned 503?
- Frequently asked questions
Key takeaways
- RFC 9110 defines 503 Service Unavailable as a temporary overload or maintenance condition. The server may send a Retry-After header, given either in seconds or as an HTTP date.
- WordPress core returns its own 503 with Retry-After: 600 while an update runs. A leftover .maintenance file keeps that response going until someone deletes the file and runs the update again.
- Check the status with curl or the browser’s Network panel while logged out. Logged-in admins skip maintenance pages, and a page can look like a maintenance screen while it returns 200.
- Google’s Search Central guidance says a 503 is right for a short pause of a few days at most. For a longer closure, serve a 200 placeholder page, and don’t use robots.txt to shut the site down.
- Retrying a page view is usually harmless. Retrying a checkout or form submission is not, because the server may have finished the action before something else returned the 503.
A 503 is the one server error that is designed to be sent on purpose. It tells the browser, and Google, “not right now, try again later.” That is very different from “this page is broken” or “this page is gone.” It also says nothing about what caused it, which explains why people often fix the wrong thing.
This article covers what the code means, how to read it, and how to work out which part of a WordPress setup sent it. If your site is down right now and you want the repair steps, our guide on how to fix a 503 error on WordPress goes through them in order.
What does a 503 response code actually say?
It says the server is temporarily unable to handle the request, usually because of overload or maintenance. Section 15.6.4 of RFC 9110, the HTTP semantics standard, defines it this way, and MDN’s 503 reference describes the server as “not ready to handle the request.”
“Temporary” describes what the server intends. It doesn’t mean the problem will clear by itself. An overloaded server may recover when traffic drops. A maintenance setting someone forgot to switch off will keep returning 503 for weeks. The two produce the same number.
The server may add a Retry-After header, given either as a number of seconds or as an HTTP date. When it’s there, the server is estimating how long you should wait. When it’s missing, nobody has given an estimate, and you should treat the 503 like any other server error you need to investigate.
How do you read the 503 instead of the error page?
Look at the response headers. The wording on the page is the least reliable evidence you have. A CDN can put its own branded page in front of an error from your host, and a maintenance plugin can show a friendly holding page that doesn’t return a 503 at all.
In Chrome or Firefox, open Developer Tools, go to the Network tab, reload, and click the first request (the document itself, not an image). Under Headers, note the status code, any Retry-After value, any Server or CDN headers, and the time. From a terminal, this prints the headers of a real GET request:
curl -s -o /dev/null -D - https://example.com/
HTTP/2 503
retry-after: 600
content-type: text/html; charset=utf-8Plain curl -I also works, but it sends a HEAD request, and some caches and firewalls answer HEAD differently from GET. If the two disagree, trust the GET.
Test while logged out, in a private window or with curl. WordPress maintenance plugins let logged-in administrators through, so the owner sees a normal site while every visitor gets the holding page.
Which part of a WordPress site sent the 503?
There are five usual sources. Where the 503 appears, and when, tells you more than the code does. A 503 on every URL points somewhere different from a 503 that only hits checkout or only appears while you save a post.
| Source | What you usually see | Check first |
|---|---|---|
| WordPress core, mid-update | “Briefly unavailable for scheduled maintenance. Check back in a minute.” on every URL | A .maintenance file in the WordPress root |
| A maintenance or coming-soon plugin | A branded holding page for visitors, a normal site for admins | The plugin’s on/off setting, tested while logged out |
| Hosting resource limits | Cached pages load, while checkout, login, search and wp-admin fail, often at busy times | The host’s CPU, memory, process and PHP worker graphs at the time of the error |
| A security layer | One action fails, such as saving many product variations or connecting an account | The firewall or ModSecurity log entry for that request |
| A CDN or proxy | A CDN-branded page, or an error that remains after the origin recovers | The same URL with the CDN bypassed |
Core maintenance is the easiest to recognise
During an update, WordPress puts a .maintenance file in the site root. While that file exists, the core function wp_maintenance() answers every request with a 503 and Retry-After: 600, which asks clients to come back in ten minutes. If the update is interrupted, the file stays and so does the 503. WordPress.org’s troubleshooting FAQ says to delete the file and then run the update again. Deleting the file clears the message. It does not finish the update. Our article on why WordPress updating failed covers that second half.
Resource limits are the most common cause, and the most misread
Nobody publishes data on how often each cause occurs. In support threads, though, the cause reported most often is the host running out of capacity. On most hosts, PHP workers are the processes that build WordPress pages that aren’t cached. When every worker is busy, new requests wait in a queue, time out, and come back as 503s. Cached pages skip the workers completely. That’s why a store’s homepage can look fine while checkout fails, because checkout, cart, login and admin pages are never served from the page cache.
A bigger plan or more memory only helps if you’ve confirmed that a limit is actually being hit. More workers need more RAM and send more simultaneous queries to the same database. If one slow query or plugin is holding workers, more capacity just postpones the next outage. In one WordPress.org WooCommerce support thread, the host said the site needed a VPS. The 503 actually went away when the owner replaced a product-category element on the home page.
Security rules can return 503 to a single action
WooCommerce’s documentation on large data not saving names servers running mod_security, along with PHP’s max_input_vars limit, as reasons why saves of product variations and tax rates fail. If the 503 only appears on one form or one admin action, look for the rule that matched that request. Don’t switch the firewall off. Ask the host for a targeted allow rule instead.
A CDN usually relays the 503 rather than causing it
If the error page carries a CDN’s logo or a request ID, that only proves the request went through the CDN. Most CDN-delivered 5xx errors start at the origin server. Bypass the CDN (most offer a development or pause mode) and request the same URL again. If the 503 disappears, the CDN is serving a cached error, and purging that URL fixes it. If it stays, the problem is at the origin.
How is a 503 different from a 500, 502, 504 or 429?
The other codes describe a fault, a broken handoff or a single client over its limit. A 503 describes a service that is unavailable for now. That changes what you do next.
| Code | What it means | What it suggests on WordPress |
|---|---|---|
| 500 Internal Server Error | The server failed and gave no reason | A PHP fatal error, a bad .htaccess rule or a memory error. See our guide to the 500 error |
| 502 Bad Gateway | A proxy got an invalid response from the server behind it | PHP crashed or the PHP-FPM socket is down behind Nginx or a CDN |
| 503 Service Unavailable | Temporarily unable to handle the request | Maintenance, full worker pools or a deliberate block |
| 504 Gateway Timeout | A proxy gave up waiting for the server behind it | A slow query, import or remote API call that ran past the proxy’s timeout |
| 429 Too Many Requests | This client is over a rate limit | A security plugin or host throttling one IP. The site is up for everyone else |
Hosts don’t always pick the textbook code. Some stacks turn a PHP crash into a 503 instead of a 502, so use the table to decide where to look first, not as proof of the cause. If the PHP error log shows a fatal error at the same timestamp, follow the log. Our WordPress fatal error guide shows how to read the file path it names. WordPress.org’s Recovery Mode documentation notes that Recovery Mode doesn’t activate for fatal errors in cron or background tasks, so a missing recovery email doesn’t mean nothing failed.
When is it safe to retry a 503?
When the request only reads something. Reloading a page or fetching an image is a GET request, and repeating it changes nothing. Under heavy load, though, every reload occupies a worker again, so wait for the Retry-After period if there is one. Refreshing again and again makes an overloaded server slower to recover.
Checkouts, form submissions and cart updates are different. The server may have recorded the order or taken the payment before a proxy or a timeout sent the 503 back. Before anyone resubmits, check the WooCommerce orders list, the payment provider’s dashboard or the form plugin’s entries. A 503 on a POST tells you the response failed. It doesn’t tell you the action failed.
For scripts and integrations that call your site, use bounded exponential backoff with jitter. That means waiting longer after each failure, adding a random offset so clients don’t retry in sync, capping the delay, and stopping after a fixed number of tries. Tight retry loops from monitors and integrations are a common way a brief overload turns into a long one.
When should your site return a 503 on purpose?
When you take it offline for a short, planned reason: a migration, a database restore, a pause in sales. Google’s guidance on temporarily pausing or disabling a website recommends a 503 page for brief shutdowns lasting a few days at most. The page should be lightweight, include a Retry-After header and tell visitors when you’ll be back or how to reach you. Google’s crawl-rate documentation puts the window at a couple of hours to one or two days. If the closure will run longer, serve a normal 200 placeholder page instead. A 503 that lasts weeks tells Google the site is unreliable.
The same page warns against two shortcuts: blocking the site in robots.txt, and adding noindex to shut it down. Both are harder to undo than a status code.
A few habits keep planned downtime honest:
- Check the status, not the look. Run curl while logged out and confirm you get 503 and not 200. A maintenance page that returns 200 tells search engines the holding page is your content.
- Prefer a server-level 503 for real work. A rule in
.htaccess, Nginx or the CDN keeps working even when PHP or the database is the thing you’re working on. A plugin-based 503 needs WordPress to load before it can respond. - Clear every cache when you finish. The WordPress cache, the host’s server cache and the CDN each store their own copy. Visitors can keep seeing the holding page after you switch it off, or see the live site while the plugin still thinks it’s on.
Our article on coming soon text in WordPress covers the visible side: what the holding page should say.
What should you do with an unplanned 503?
Write down the URL, the time with time zone, the status, the headers and which actions fail. Then match that against the table above before you touch a plugin. Disabling every plugin on a live store removes checkout, forms and security together. It often hides the evidence too, and it rarely helps when the real problem is a full worker pool. If the host’s graphs show a limit being hit at that timestamp, send them that evidence. If the PHP log names a file, start there. The step-by-step 503 fix covers plugin isolation over FTP, Health Check troubleshooting mode and the CDN purge.
If you’d rather not dig through logs yourself, SiteSelf can find and fix the failing layer on request through chat. It needs hosting (SSH) access for log and file work, and it reports what it changed and what it checked.
When the site is back, check the things a working homepage can hide. Load checkout and wp-admin while logged out and logged in. Reconcile any orders placed while the site was failing. Confirm that scheduled posts actually went out, because WP-Cron only runs when visitors load pages, and nobody got through during the outage.