How to Fix HTTP 503 Service Unavailable (2026)

TL;DR

HTTP 503 Service Unavailable means the server received your request and refused to process it. The connection worked, TLS worked, and the request parsed. This is a capacity, maintenance, or policy decision made after the request arrived, not a DNS or certificate problem.

Before touching anything, find out which layer answered. Run curl -I and read the Server header and any CDN identifiers. A 503 from a CDN or load balancer means the origin never saw the request. A 503 from nginx, Apache, or IIS means the origin answered and said no.

As a visitor there is little to do beyond checking Retry-After and waiting. As the site owner it is usually an exhausted worker pool, a maintenance flag nobody removed, or a load balancer with no healthy targets. As a scraper, a 503 is often a soft block wearing an outage costume.

Most guides for this error assume WordPress and send you plugin hunting. In this article, we'll explore what a 503 means at the protocol level, how to identify which layer produced it, and how to fix it from either side of the connection.

What HTTP 503 Actually Means

The spec is narrow. MDN defines it as the server not being ready to handle the request, with maintenance and overload as the common causes, and notes the response should carry a Retry-After header giving an estimated recovery time. Everything else people attach to this code is inference.

The keyword here is received. Your client completed a TCP connection, finished the TLS handshake, and sent a valid request. Something on the other side chose to return 503 instead of content. That rules out half the fixes you will find elsewhere, because clearing a browser cache cannot influence a decision made on the server.

503 versus 502, 504, and 429

A 502 means the server that answered got a malformed response from something upstream. A 504 means that upstream took too long. A 503 means the server that answered decided not to try at all.

The 429 distinction matters most and it is where most articles are wrong. When a specific client is being restricted for rate limiting, the correct response is 429 Too Many Requests. Plenty of stacks return 503 anyway, which is why a 503 during scraping deserves a second look.

Read Retry-After before anything else

Retry-After takes either a delay in seconds or an HTTP date. A 503 carrying one is almost always deliberate, meaning maintenance or shed load. A 503 with no Retry-After and an HTML body is usually something failing rather than something planned.

ABAP

curl -sI https://example.com | grep -Ei 'HTTP/|retry-after|server|via|cf-ray'

That one command gives you the code, the wait, and the software that emitted it. A cf-ray header or a CDN name in Server means the edge answered and your origin may be fine.

Also Read: Web Scraping Best Practices: Complete

Fixing a 503

Work down from the layer that emitted it rather than through a list of plugins.

On your own site

An exhausted worker pool is the most common cause. PHP-FPM with pm.max_children set too low queues requests until nginx gives up and returns 503, and the FPM log says so directly. Raising the limit without checking free memory just moves the failure to the OOM killer.

Your own throttle can look identical. The nginx limit_req and limit_conn directives return 503 by default, so set limit_req_status 429 and stop confusing the two.

A failed update can also leave a maintenance flag in place, and the site stays 503 until that file is deleted. Check for it before assuming a resource problem.

Behind a load balancer the cause moves. AWS returns 503 from an Application Load Balancer when the target group has no registered targets, which also happens when every target fails its health check. The AWS troubleshooting docs list the exact checks, and the same logic applies to Kubernetes with no ready pods behind a service.

One thing worth knowing: a short 503 tells Googlebot to come back later, but weeks of it and the pages drop out of the index.

When it is a block rather than an outage

If a page loads in your browser and returns 503 to your scraper on the same network, the site is not down. The tells are consistent. The 503 arrives instantly, there is no Retry-After, the body is a challenge or generic block page, and it follows one IP rather than the target.

Retrying that in a tight loop is the fastest way to turn a soft block into a hard ban. Honor the wait when there is one and back off when there is not.

PYTHON

import time, requests

def get(url, proxies=None, tries=5):
    for n in range(tries):
        r = requests.get(url, proxies=proxies, timeout=20)
        if r.status_code != 503:
            return r
        wait = int(r.headers.get("Retry-After", 2 ** n))
        time.sleep(min(wait, 60))
    return r

Backoff alone will not clear a 503 tied to IP reputation, because the block follows the address rather than the pace. Proxyon spreads requests across clean exits so one flagged address does not stall the job, with residential proxies for protected targets, datacenter proxies for everything else, on pay-as-you-go pricing.

Also Read: How to Set Up Rotating Proxies for Web Scraping

FAQ Section

What does HTTP 503 mean?

The server got your request and refused to handle it, usually because of overload or maintenance. The connection itself succeeded, which is what separates 503 from a DNS or TLS failure.

Will a 503 error fix itself?

Often yes, since the code is meant for temporary conditions. If it outlasts the Retry-After window or runs for hours, something is broken rather than busy.

How do I fix a 503 as a visitor?

Reload after a minute, then confirm the site is down for everyone with an external uptime checker. If it is only you, test from another network or with your VPN off, since the block may be aimed at your IP.

What is the difference between 502, 503, and 504?

A 502 means a bad response from upstream, a 504 means upstream timed out, and a 503 means the server that answered chose not to process the request at all.

Why does my scraper get 503 when the browser loads fine?

That is a soft block rather than an outage. Slow the request rate, respect Retry-After, and rotate the exit IP, since the restriction usually follows the address.

Does a 503 error affect SEO?

Short ones do not, because Google reads them as temporary and retries. Extended 503s stop crawling and eventually push pages out of the index.

Final Thoughts

Identify the layer before you fix anything. One curl -I tells you whether the CDN, the load balancer, or the origin produced the 503, and that answer decides which half of this guide applies. On your own site it is usually a worker pool, a health check, or a maintenance flag nobody cleaned up. In a scraper it is usually a block, and the fix is backing off properly and spreading traffic across cleaner IPs rather than retrying harder.