Try now
Back to blog

HTTP 503 Service Unavailable: What It Means and How to Fix It

HTTP 503 Service Unavailable: What It Means and How to Fix It

A 503 Service Unavailable response means the server received your request but cannot handle it right now, usually because it is overloaded, under maintenance or waiting on a component behind it. The status is meant to be temporary: the site has not vanished, and the same page often loads after a pause. When a 503 keeps coming back, though, something specific is in the way, and finding it depends on where you sit.

This guide is split by audience. Visitors get a short list of things worth trying. People who fetch pages through proxies or run scrapers learn how to tell whether the error came from the target site, its CDN or the proxy itself, and how to retry without making things worse. Site owners get a diagnostic order and a note on how search engines treat the code.

Rotating proxies

Rotating proxies that spread requests across many IPs and cut throttling errors

Try it

What the 503 Status Means

The HTTP standard (RFC 9110) defines 503 as a temporary inability to handle a request because of overload or scheduled maintenance. The server may add a Retry-After header that says when to come back, either as a number of seconds or as a date. Any machine in the chain can produce the response: the application, a reverse proxy such as nginx, a load balancer, a CDN, a firewall or a forward proxy you use yourself.

The wording on screen varies: "Service Unavailable", "Service Temporarily Unavailable", "The server is temporarily unable to service your request", "No healthy upstream" or a branded maintenance page. The number in the status line is what matters.

How 503 Differs from Similar Codes

CodeMeaningTypical cause
500 Internal Server ErrorThe application crashed while handling the requestA bug or failed script
502 Bad GatewayA gateway got an invalid reply from the server behind itBackend crashed or returned garbage
503 Service UnavailableThe service is up but refuses work for nowOverload, maintenance, no healthy backends, throttling
504 Gateway TimeoutA gateway waited too long for the backendSlow application or database
429 Too Many RequestsThe client sent too many requestsRate limiting aimed at one client

Strictly speaking, rate limits belong to 429, yet plenty of sites answer heavy clients with 503 instead. Keep that in mind if you send automated traffic.

Why a Server Returns 503

  • Planned maintenance. Deployments and updates switch the site into a maintenance mode that answers 503 on purpose.
  • Traffic spikes. A sale, a news mention or a bot wave exhausts worker processes, database connections or memory.
  • A slow dependency. The web server is fine, but the database, cache or an external API it waits on is not, so requests pile up.
  • No healthy backends. A load balancer or CDN marks every origin server as down after failed health checks.
  • Protection layers. A web application firewall or anti-bot system rejects suspicious clients and picks 503 as its reply.
  • A proxy that cannot reach the target. Forward proxies answer 503 when they fail to connect to the destination or have no exit available.

What to Try as a Visitor

  1. Wait a minute and reload the page. Most 503s caused by load or deployments clear quickly.
  2. Open the site in a private window or with extensions off, to rule out a broken cached session or a blocker.
  3. Try another network, for example mobile data instead of office Wi-Fi.
  4. If you browse through a proxy or VPN, turn it off for a moment. When the page loads directly, the problem sits with the route rather than the site.
  5. Check the site's status page or social accounts for an outage notice.

Clearing the browser cache rarely fixes a 503, because the code comes from the server. If the page stays down for hours, the owner has to act.

503 Errors When Working Through Proxies

For anyone collecting data or testing sites through a proxy, a 503 has three possible authors: the target site, a CDN or firewall in front of it, or the proxy you route through. Each calls for a different fix, so identify the source first.

Step 1. Find Out Who Answered

Send the same request with verbose output, once directly and once through the proxy:

curl -sv -o /dev/null https://example.com/catalog
curl -sv -o /dev/null -x http://user-7f3k:Pa55word@203.0.113.17:8000 https://example.com/catalog

Read the output from top to bottom:

  • CONNECT tunnel failed, response 503 means the proxy itself refused to open a tunnel to the site. The target never saw your request.
  • A 503 after the TLS handshake came from the site or its edge. Look at the Server, Via and Proxy-Status headers and at vendor headers such as a CDN request ID.
  • A 503 only through the proxy, while the direct request is fine, points to the proxy's IP being throttled or blocked by the site.

To check the proxy on its own, run it through a proxy checker: it shows whether the server answers and which exit IP it uses.

Step 2. When the Proxy Is the Source

A gateway returns 503 when it cannot reach the target host, when the requested country or session has no free IP at that moment, or when the account hit a limit. Check the dashboard for traffic and thread limits, try another geo or session ID, and verify the host and port in your settings. Persistent tunnel failures to one domain while other sites work usually mean the destination refuses that network.

Step 3. When the Site Throttles You

Many large platforms answer automated traffic with 503 rather than 429. Retail marketplaces are a classic case: their robot check page arrives with a 503 status and a polite note about automated access. Signs that you are being throttled:

  • errors start after a burst of requests and fade after a pause;
  • one IP is refused while a fresh one from the same pool gets through;
  • the response body is a captcha or an "unusual traffic" page rather than the usual layout.

The remedy is to look less like a flood. Slow down, spread requests across addresses with rotating proxies, keep realistic headers and keep cookies within a session. Our checklist on avoiding blocks while scraping goes deeper, and the overview of how sites detect bots explains which signals give a scraper away.

Step 4. Retry With Backoff

Hammering a struggling server only extends the outage and burns proxy traffic. Respect Retry-After when it is present and back off exponentially when it is not:

import random
import time

import requests

PROXY = "http://user-7f3k:Pa55word@203.0.113.17:8000"
session = requests.Session()
session.proxies = {"http": PROXY, "https": PROXY}


def get_with_backoff(url, tries=5):
    for attempt in range(tries):
        resp = session.get(url, timeout=25)
        if resp.status_code != 503:
            return resp
        header = resp.headers.get("Retry-After", "")
        # Retry-After can also be an HTTP date; fall back to backoff then
        pause = int(header) if header.isdigit() else min(2 ** attempt * 3, 90)
        time.sleep(pause + random.uniform(0.2, 1.5))
    return resp

Cap the number of tries and log every 503 with the proxy IP and timestamp. Patterns in that log show whether one address, one geo or one time of day is the problem. For other failure types, see our list of common scraping errors.

How Site Owners Can Track Down a 503

Work from the outside in, so you do not restart services blindly:

  1. Confirm the code and the scope. Is it every page or only some, every region or one? Check from an external monitor.
  2. Read the edge first. CDN and load balancer logs show whether origins failed health checks or the edge itself throttled traffic.
  3. Check server resources. CPU, memory, disk space, open connections and the count of busy worker processes (PHP-FPM, Gunicorn and similar).
  4. Inspect logs. Web server error logs and application logs around the first 503 usually name the bottleneck.
  5. Test dependencies. Database connection pool, cache, queues and external APIs.
  6. Review firewall rules. A new WAF rule or rate limit can return 503 to legitimate visitors.
  7. Compare with recent changes. A deployment, plugin update or config edit just before the errors is the prime suspect.

On WordPress, a stuck maintenance mode after an interrupted update leaves a .maintenance file in the site root; removing it brings the site back. A plugin that floods the database is another frequent culprit, so disabling plugins one by one is a reasonable test.

To prevent repeats, add caching, queue heavy background work, scale workers before known peaks, roll out updates gradually and alert on the share of 5xx responses.

How 503 Affects SEO

Search engines read 503 as "come back later", which is exactly why maintenance pages should return it instead of 200. Google slows down crawling when it meets 5xx or 429 responses and retries later. A short outage does no harm, but URLs that keep answering 503 for days may start dropping from the index. Add Retry-After during planned work and keep it brief.

HTTP 503 FAQ

Is a 503 error my fault or the website's?

Almost always the website's or a server in front of it. The exception is automated traffic: a site can return 503 to a client that sends too many requests, or a proxy you use can fail to reach the target.

How long does a 503 error last?

Load spikes and deployments usually clear within minutes. If the page stays down for hours, the owner is dealing with a larger failure or long maintenance.

Why do I get 503 only through a proxy?

The site or its CDN is probably throttling that IP, or the proxy cannot open a tunnel to the destination. Compare a direct request with a proxied one and check whether curl reports a failed CONNECT tunnel.

Should a scraper retry after a 503?

Yes, but with growing pauses and a limit on attempts. Honour the Retry-After header when the server sends one, and switch IPs if one address keeps getting refused.

Does a 503 hurt search rankings?

A short one does not. Search engines treat it as temporary, but pages that return 503 for several days can lose crawl priority and eventually fall out of the index.