HTTP 503 Service Unavailable: what it means and how to fix it

A 503 Service Unavailable response means the server cannot handle your request right now. The server itself is reachable – it received your request, understood it, and intentionally responded with a 503. But something behind it is temporarily unable to do the work.

This is different from a timeout or a connection failure. A 503 is a deliberate response. The server is telling you: “I’m here, I’m running, but I can’t serve this request at this moment.” The HTTP specification defines 503 as a temporary condition, which means the request might succeed if you try again later.

What a 503 actually means in the HTTP specification#

HTTP 503 is defined in RFC 9110, Section 15.6.4. The specification says the server is currently unable to handle the request due to temporary overloading or scheduled maintenance. The key word is “temporary” – a 503 indicates the condition will resolve itself, unlike a 500 Internal Server Error which often points to a broken application.

The server may include a Retry-After header in the response:

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/html

The Retry-After value can be a number of seconds (like 120 ) or an HTTP date (like Wed, 09 Apr 2026 12:00:00 GMT ). This tells the client how long to wait before retrying. Not all servers include this header, but well-configured ones do, and browsers and crawlers that respect it will back off instead of hammering the server with retries.

Common causes of a 503#

Server overload

The most common cause. The server is running, but the application behind it has more requests than it can handle. This is especially common on shared hosting environments where multiple sites compete for resources.

On a typical web server, the chain looks like this: the web server (Nginx, Apache, or a load balancer) receives the request and passes it to an application backend – PHP-FPM for WordPress, a Node.js process, a Python WSGI server, or something similar. If that backend has no available workers to handle the request, the web server returns a 503.

This happens during:

• Traffic spikes that exceed your server’s capacity
• Bot traffic consuming resources that should serve real visitors
• Slow database queries holding up application workers
• Memory exhaustion causing the application to reject new connections

Application crashes

If the application backend crashes or fails to start, the web server has nothing to pass requests to. Every request returns a 503 until the application is restarted.

This is different from overload. With overload, the application is running but overwhelmed. With a crash, the application is completely down. The distinction matters for troubleshooting – overload may resolve itself when traffic drops, but a crashed application needs manual intervention or an automatic restart mechanism.

Scheduled maintenance

A 503 is the correct status code to return during planned maintenance. It tells browsers and search engines that the downtime is intentional and temporary. This is far better than returning a 200 with a “we’ll be right back” page, because a 200 tells crawlers to index the maintenance page as if it were real content.

WordPress maintenance mode plugins typically return a 503 during plugin and core updates. If you see a 503 immediately after triggering an update, this is expected and should resolve within seconds.

Deployment windows

Deploying a new version of an application often involves restarting processes. During that restart window – however brief – the application cannot serve requests. On a single-server setup, this produces 503 responses for any requests that arrive during the restart.

Load balancers and rolling deployments solve this by taking one server out of rotation at a time, but simpler setups will produce brief 503 windows during every deploy.

Rate limiting and throttling

Some servers return a 503 when a client exceeds a rate limit, though 429 Too Many Requests is the more appropriate code for this. If you see 503 responses that only affect specific IPs or user agents, rate limiting is a likely cause. Check your web server and WAF configuration.

CDN and proxy failures

If your site is behind a CDN like Cloudflare, AWS CloudFront, or a reverse proxy, the 503 might originate from the CDN itself rather than your server. CDNs return a 503 when they cannot reach your origin server. Cloudflare labels these with specific error codes (like Error 521 or Error 522) to help distinguish CDN-level failures from origin-level failures. See 520 and 521 web server errors for more on proxy-origin communication failures.

Database connection exhaustion

Applications that depend on a database – which is most web applications – can return a 503 when the database connection pool is full. WordPress connects to MySQL on every page load. If MySQL hits its connection limit, PHP cannot complete the request, and the web server returns a 503 to the visitor.

How to diagnose a 503#

Check the response headers

The response headers often tell you which layer generated the 503. Open your browser’s developer tools (F12, Network tab) and look at the response:

HTTP/1.1 503 Service Unavailable
Server: nginx
Retry-After: 30

The Server header tells you which software generated the response. If it says cloudflare or AmazonS3 , the 503 came from the CDN or proxy, not your origin server. If it says nginx or Apache , the 503 came from your web server.

You can also check from the command line using curl:

curl -I https://example.com

Check the error logs

The error log is the most reliable source of information. Where you check depends on your web server:

Nginx:

tail -f /var/log/nginx/error.log

For Nginx-specific 503 troubleshooting – PHP-FPM pool exhaustion, upstream failures, and rate limiting configuration – see our detailed guide on 503 Service Temporarily Unavailable in Nginx.

Apache:

tail -f /var/log/apache2/error.log

Application logs (WordPress, Node.js, etc.) may have additional detail about why the backend failed. For WordPress, enable debug logging in wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This writes errors to wp-content/debug.log without displaying them to visitors.

Determine the scope

Is it every page or just specific ones? Is it every visitor or just you? Is it constant or intermittent?

• Every page, every visitor – the application backend is down or completely overloaded
• Specific pages only – those pages trigger a slow or resource-intensive operation
• Intermittent – the server is near capacity and occasionally runs out of workers
• Only from certain IPs – rate limiting or firewall rules

Check resource usage

If you have SSH access, check the server’s resource usage:

top -bn1 | head -20
free -m
df -h

High CPU, exhausted memory, or a full disk can all cause 503 responses. The systemctl command can tell you if the application service has crashed:

systemctl status php-fpm
systemctl status nginx

How to fix a 503#

If the application backend is down

Restart it. For PHP-FPM:

sudo systemctl restart php-fpm

For a Node.js application managed by systemd:

sudo systemctl restart your-app

Check whether the application starts successfully. If it crashes again immediately, the error logs will tell you why – a configuration error, a missing dependency, or a resource limit being hit at startup.

If the server is overloaded

This is a capacity problem, and the fix depends on where the bottleneck is.

PHP-FPM pool exhaustion is the most common cause on WordPress hosting. Your PHP-FPM pool has a maximum number of worker processes. When all workers are busy, new requests are rejected. You can check the current pool status and adjust the limits – see how PHP-FPM works for configuration details.

Bot traffic consuming workers is a frequent cause on WordPress sites. Check your access logs for repeated requests from the same IP or user agent, especially to expensive endpoints like wp-login.php , xmlrpc.php , or wp-cron.php . Rate limiting and server-level bot detection can prevent bots from consuming resources meant for real visitors.

Slow database queries keep workers occupied longer than they should be. Optimizing your WordPress database and adding proper indexing reduces how long each request holds a worker.

If it is a CDN or proxy issue

If the 503 originates from your CDN, the problem is between the CDN and your origin server:

1. Verify your origin server is running and accepting connections
2. Check that the CDN has the correct origin IP address
3. Verify your SSL certificate is valid – CDNs often fail to connect if the origin certificate is expired
4. Check your origin’s firewall is not blocking the CDN’s IP ranges

If it is during maintenance

If you triggered the maintenance intentionally, wait for it to complete. If WordPress is stuck in maintenance mode, delete the .maintenance file from your WordPress root directory:

rm /path/to/wordpress/.maintenance

This file is created automatically during updates and should be removed automatically when the update finishes. If the update failed partway through, the file may remain.

If it is a database connection issue

Check whether MySQL is running and accepting connections:

sudo systemctl status mysql
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"

If the connection count is at or near max_connections , you need to either increase the limit or find what is consuming all the connections. See MySQL too many connections for the full diagnosis process.

503 and SEO#

A 503 is the least harmful server error for SEO – when handled correctly. Google’s crawler treats a 503 as a temporary signal and will return later to check again. This is the intended behavior defined by the HTTP specification.

Short 503 periods (minutes to a few hours) have no measurable impact on rankings. Google expects servers to have occasional downtime and does not penalize sites for it.

Extended 503 periods (days or weeks) will cause Google to reduce crawl frequency and eventually drop pages from the index. If your site returns 503 for an extended period, Google assumes it is no longer available.

Using 503 for maintenance is the correct approach. Return a 503 with a Retry-After header during planned downtime. This tells Googlebot to come back later rather than indexing a maintenance page or assuming the content is gone.

Do not use 503 as a permanent block. If you want to permanently remove a page, use a 410 (Gone) or 404 (Not Found). A 503 tells crawlers the page will return, so they keep checking.

The worst thing you can do for SEO during downtime is return a 200 with a “down for maintenance” message. That tells search engines your content has been replaced with a maintenance notice, and they may index it.

503 vs other 5xx errors#

The key difference between 502 and 503: a 502 means the web server got a response from the backend, but the response was invalid. A 503 means the backend could not accept the request at all – it was either down, overloaded, or explicitly refusing connections.

The key difference between 503 and 504: a 503 is an immediate refusal. A 504 is a timeout – the backend accepted the connection but never finished responding. Pool exhaustion can produce either error depending on configuration. If the queue rejects immediately, you get a 503. If the request sits in the queue until a timeout, you get a 504.

What to tell your hosting provider#

If you cannot resolve the 503 yourself, contact your hosting provider with:

• The exact URL(s) returning 503
• When it started and whether it is constant or intermittent
• Whether it affects all pages or specific ones
• What changed before the error appeared (new plugin, traffic spike, DNS change)
• Any error messages from the response body or developer tools
• The response headers, especially the  Server  and  Retry-After  values

This information lets the support team skip the basic diagnostic questions and go straight to the server-side investigation.

Summary#

A 503 Service Unavailable means the server is running but temporarily cannot handle your request. The most common causes are application overload, crashed backend processes, scheduled maintenance, and CDN connectivity failures. Unlike most server errors, a 503 is designed to be temporary – the server is explicitly telling you to try again later.

For WordPress on Nginx specifically, 503 Service Temporarily Unavailable in Nginx covers PHP-FPM pool exhaustion, upstream failures, and Nginx-specific configuration in detail. For other HTTP status codes, see the HTTP 2xx success codes, HTTP 302 redirect, and HTTP 429 Too Many Requests guides.