503 Service Unavailable: What It Means and How to Fix It Step by Step

A 503 Service Unavailable response says the server cannot handle the request right now, usually because it is overloaded or deliberately taken out of service. Unlike a 500, which signals a bug, a 503 tells you the server is alive and choosing, or being forced, to refuse work. This guide helps you decide whether yours is a planned maintenance flag, a capacity problem or a dead backend, and what to change in each case.

The status is defined in RFC 9110, and the server may include a Retry-After header suggesting when to try again. See the HTTP 503 reference for the short version.

What 503 looks like in the real world

The error is often a temporary state, but its cause varies widely:

The first step is the same as with any HTTP error: look at the full response, not just the browser's page.

curl -sI https://example.com/

Check the status line, the Server and Via headers, and whether Retry-After is present. The HTTP Header Checker shows these from outside your network, and the Maintenance Detector can tell you if a page looks like a maintenance notice rather than a failure.

Step 1: Rule out planned maintenance

Someone, or something, may have turned the maintenance switch on.

WordPress

WordPress writes a file named .maintenance in the site root while it updates a core, plugin or theme. If the update is interrupted by a timeout or crash, the file stays and the site shows "Briefly unavailable for scheduled maintenance. Check back in a minute." long after. Delete it:

ls -la /var/www/html/.maintenance
rm /var/www/html/.maintenance

Via FTP or a file manager, make sure hidden files are visible, because the name starts with a dot. After removing it, re-run the interrupted update.

Other CMS and frameworks

Laravel's php artisan down creates a maintenance state (run php artisan up to remove it), Drupal and Magento have maintenance toggles, and many deploy tools create a flag file or change a symlink. Check your deployment scripts for a maintenance step that failed halfway.

Web server rules

A rewrite or return 503; rule left in the nginx or Apache config will serve 503 to everyone:

# nginx: look for a stray rule like this
location / {
    return 503;
}

# Apache .htaccess or vhost: look for RewriteRule ... [R=503] or Redirect 503
RewriteRule ^ - [R=503,L]

Step 2: Check whether workers are exhausted

When every worker is busy, additional requests queue up and then fail. The 503 is the symptom; capacity is the disease.

PHP-FPM

sudo tail -n 100 /var/log/php8.3-fpm.log | grep -i "max_children\|slow"
sudo systemctl status php8.3-fpm

A line saying server reached pm.max_children setting is the confirmation. Increase pm.max_children only after calculating how much RAM a worker uses. If each worker averages about 60 MB and you have 2 GB reserved for PHP, then around 30 is the limit, not 100. Raising it above available memory causes swapping and the kernel OOM killer, which makes things worse. Also determine why workers are busy in the first place: a slow database query, a plugin calling a remote API with no timeout, or an expensive uncached page hit by crawlers.

Apache

Apache's MaxRequestWorkers (prefork, worker or event MPM) caps concurrent requests. The log says server reached MaxRequestWorkers setting. Check which MPM you run, and whether many workers sit in the W or R state:

sudo apachectl -V | grep -i mpm
sudo apachectl status          # requires mod_status enabled

Switching a PHP site from prefork with mod_php to event with PHP-FPM generally handles concurrency more efficiently, but changing the MPM is a significant change, so test it first.

nginx

nginx itself rarely runs out of connections, but worker_connections can be hit under extreme load and the log says worker_connections are not enough. Also look at limit_req and limit_conn zones, which return 503 by default when the limit is exceeded (you can change that to 429 with limit_req_status 429;). A rate limit that is too strict will block real visitors and monitoring probes.

Step 3: Check backends and health checks

If you use a load balancer or proxy with several servers, a 503 can mean none of them is considered healthy.

• In HAProxy, "503 Service Unavailable. No server is available to handle this request." is shown when all backends are down. Check show stat or the stats page.
• In nginx, no live upstreams produces 502 or 503 depending on the module and config.
• In cloud load balancers (AWS ALB/NLB, Azure, GCP), look at target health. A health check that points at a path requiring login, or that times out because of a slow query, will mark healthy servers as failed.

Test what the health check sees by running the same request manually against each backend:

curl -sv -o /dev/null http://10.0.0.11:8080/health

Step 4: Shared hosting limits

On shared hosting with resource isolation (often CPU, RAM, entry process and I/O limits per account), spikes cause the host to throttle or refuse requests, producing 503 or a host-specific page. A single cron job, a backup plugin or a bot crawl can trigger it. Open your control panel's resource usage graphs, find the time of the errors, then:

1. Enable page caching so that repeated views do not run PHP and the database.
2. Look in access logs for abusive bots hitting search or login URLs, and block or rate limit them.
3. Move heavy tasks like backups and imports outside peak hours.
4. If limits are consistently hit with normal traffic, you have outgrown the plan.

Step 5: IIS and Windows

For IIS, a 503 on every page often means the application pool is stopped. Open IIS Manager, check Application Pools, and start the pool. If it stops again, Rapid-Fail Protection may be disabling it after repeated crashes; the Windows Event Viewer (System log, source WAS, and the Application log) tells you which worker process failed and why. Common causes are a bad identity password, a corrupt web.config, or a crashing application. Also confirm the queue length of the pool is not at its limit.

Step 6: Check upstream dependencies and the platform

Sometimes the 503 comes from outside your server. A CDN or platform provider may be having an incident, an API gateway may be throttling you, or a managed platform (an app host with autoscaling and cold starts) may be returning 503 while instances start. Compare the response headers with what you expect from your own stack; if the Server header is a provider you do not run yourself, check that provider's status page.

A short decision path

1. Does the response include Retry-After or a maintenance message? Check for a maintenance flag or intentional rule.
2. Does the log show workers or connections exhausted? Reduce load, add caching, tune limits to available memory.
3. Is the backend service stopped or unhealthy? Start it, fix the health check.
4. Is it a shared-host limit page? Check resource graphs and ask the host.
5. Is the error only at particular times or from particular clients? Look for rate limiting, bots or scheduled jobs.

Make your own 503s helpful

If you deliberately take the site offline, return a proper 503 with a Retry-After header and a human-readable page, rather than a 200 page saying "down for maintenance" that search engines might index. In nginx:

location / {
    add_header Retry-After 3600 always;
    return 503;
}

Keep a status page hosted elsewhere so visitors get updates, and use the Uptime Monitor so you learn about unplanned 503s quickly. If load is the underlying cause, the Website Speed Test helps expose slow responses before they turn into capacity errors, and reducing time to first byte covers the server-side causes.

When to call your host

Open a ticket if the 503 is host-branded, persists after you have removed maintenance flags, or you cannot see which limit is being hit. Ask them: were the account's processes or memory limits reached at that time, is PHP-FPM or Apache restarting, and is anything wrong on the server? Provide timestamps with timezone and the output of curl -I.

Next steps

Related tools and guides:

• HTTP Header Checker to view Retry-After and server headers
• Maintenance Detector to see whether a page is in maintenance mode
• Website maintenance mode done right
• Fix 502 Bad Gateway
• Fix 504 Gateway Timeout
• How to build a website status page

FAQ

Is a 503 error temporary?

By definition it signals a temporary condition, and it can resolve on its own when load drops or maintenance ends. However, it persists when the cause is structural, such as a stopped service, a leftover maintenance flag or a worker limit that is always exceeded.

How is 503 different from 500?

A 500 means the server hit an unexpected error while processing the request, typically an application bug or configuration fault. A 503 means the server is unable or unwilling to process requests at the moment, for reasons such as overload or maintenance. The distinction guides where you look first.

Why does WordPress show "Briefly unavailable for scheduled maintenance" forever?

An update was interrupted and the .maintenance file in the WordPress root was not removed. Delete that file via FTP, SSH or your file manager, then rerun the update. Hidden files must be visible for you to see it.

Does a 503 hurt my SEO?

A brief 503 with a sensible Retry-After is the recommended way to signal temporary downtime, and crawlers will typically retry later. Extended or repeated 503s can reduce crawling and may eventually affect indexing, so fix chronic ones.

Should I just upgrade my server?

Only after confirming that capacity is the cause. Many 503s come from uncached pages, slow queries or bots, which are cheaper to fix than larger hardware. Check logs and resource graphs first, then decide.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.