503 Service Unavailable: Causes and How to Fix It

A 503 Service Unavailable is the most honest of the server errors. The machine is running and reachable — it simply cannot serve the request at this moment. That might be overload, a deploy, a crashed worker pool, or a deliberate decision by the site owner to take the site offline.

Because 503 is used both accidentally and on purpose, the first thing to establish is which one you are looking at. A 503 that appears with no maintenance window is a fault. A 503 that appears during a scheduled deploy may be entirely correct.

How 503 differs from 500, 502, and 504

All four are server errors, and they point at different things:

• 500 Internal Server Error — the application was asked to build the page and failed. Nothing in front of it gave up.
• 502 Bad Gateway — the proxy got an unusable answer. Something upstream is down or misconfigured.
• 504 Gateway Timeout — the upstream was too slow and the proxy stopped waiting.
• 503 Service Unavailable — the server answered, and the answer was “not now.” It is a deliberate, well-formed response rather than a failure to respond.

The practical difference is that a 503 usually comes from your application or its platform, while 502 and 504 come from the layer in front of it. If you are seeing a 503, the application is at least alive enough to reply.

The Retry-After header decides everything

A 503 may carry a Retry-After header, and its presence is the clearest signal of intent:

Header present	Meaning	What to do
Retry-After: 3600	Deliberate. The site will be back at a known time.	Wait, or investigate if you did not schedule it
No header	The application is failing to serve requests	Treat it as an incident

Search engines read this header too. A 503 with Retry-After tells a crawler “come back later,” which is the correct and supported way to take a site down for maintenance without losing rankings. A 503 without it is treated more cautiously over time.

Causes, and how to tell them apart

Symptom	Most likely cause	Where to look
503 on every request, with a maintenance page	Deliberate maintenance mode or a deploy	Deploy pipeline, app config
503 under traffic spikes, fine when quiet	Resource exhaustion or a full connection pool	Load average, pool metrics
503 from a CDN, origin healthy	Rate limiting or a security rule	CDN firewall and rate-limit rules
503 on one host in a pool	That node failed its health check	Load-balancer pool status
503 with a database error behind it	The database is unreachable or out of connections	App log, database connection count
503 immediately after a deploy	The new build failed to start	Deploy log, container status

The site is deliberately in maintenance mode

The correct use of the code. A plugin or a platform setting puts the application into maintenance, and every request gets a 503 until it is switched off. The failure mode is forgetting to switch it back, or a deploy that sets maintenance mode and then crashes before clearing it.

Fix: check the application’s maintenance flag first when a 503 is total and instant. If you run a maintenance window on purpose, serve the 503 with a Retry-After and a human-readable page rather than a blank screen.

A connection pool or worker pool is exhausted

The database allows 100 connections, the application opens 150, and the surplus requests get a 503 while the rest queue. This looks like a traffic problem but is a sizing problem, and it will return at the next traffic peak.

Fix: align the application’s pool size with the database’s connection limit, and add pooling or caching in front. Raising the database limit without addressing how connections are held just moves the ceiling.

Resource exhaustion on the host

CPU, memory, disk, or file descriptors at their limit. A full disk is a frequent and easily missed cause — sessions cannot be written, logs cannot be appended, and the application starts refusing requests.

Fix: check df -h and free -m before anything more exotic. Disk-full 503s are common on servers that have run for a year without log rotation.

Rate limiting or a security rule

A CDN or WAF returning 503 when it decides a client is abusive — or when a legitimate spike trips a limit set for a quieter era. Automated traffic, uptime monitors checking too often, and search crawlers can all trigger this.

Fix: check the CDN’s rate-limit and security event log before assuming the origin is at fault. A 503 that only affects some visitors is almost always this.

A failed health check removed the node

In a load-balanced pool, a node that fails its health check stops receiving traffic. If every node fails, the balancer has nothing to send to and returns 503. This is the correct behaviour working as designed — the fault is whatever made the nodes unhealthy.

Fix: look at why the health check failed, not at the balancer. A health check that depends on a slow dependency can take a healthy pool offline.

A downstream dependency is down

The application needs the database, a cache, or an identity provider, and it has decided it cannot serve requests without it. Many frameworks do this by design.

Fix: confirm the dependency is reachable from the application host, and decide whether the feature can degrade gracefully instead of failing the whole site.

If you are taking the site down on purpose

A planned 503 is the right tool, and doing it properly is what keeps it harmless:

1. Return 503, not 200. A maintenance page that returns HTTP 200 tells crawlers the page is fine and replaces your content in the index with a notice. This is the most damaging mistake in this whole article.
2. Send Retry-After with a realistic estimate.
3. Keep it short. Google’s guidance is that a 503 is treated as temporary, but a site returning it for days on end is treated as unavailable.
4. Exclude assets you can still serve so the maintenance page itself renders.

Confirming the fix

1. The status code is 200, confirmed with curl -sI https://example.com | head -1 — not just a page that looks right.
2. The Retry-After header is gone.
3. It survives a traffic peak, if overload was the cause.
4. Every node in the pool is passing health checks.

Why a recurring 503 is a search problem

A one-off 503 is a non-event: crawlers retry, and nothing is lost. A site that returns 503 regularly is a different matter. Crawlers reduce their visit rate, and if the pattern continues, the URLs are treated as unreliable and can be dropped from the index. Recovery after that takes weeks, not hours.

Because the code is temporary by definition, this is the failure that is most likely to be discovered late — visitors see a maintenance page and assume it is planned. Watching the status code from outside is what turns that assumption into a fact. SitesRadar’s free plan monitors one site’s HTTP status and alerts you the moment it starts returning 5xx, alongside uptime, SSL expiry, and DNS. For a multi-site setup, the client site down triage checklist is the order to work in when the alert arrives.

FAQ

What does a 503 mean for visitors? The site is temporarily unable to serve them. If you did not plan it, it is an incident. If you did, they should see a page that says so.

Is a 503 worse than a 404? For a page that should exist, yes. A 404 says “this is gone”; a 503 says “this will come back.” Only one of those should be temporary, and a 503 that lingers is a signal that something is broken.

Does Google penalise a 503? Google does not penalise it, but it does slow down crawling and can eventually drop URLs if the condition persists. A short, planned 503 with Retry-After is safe.

Why do I only see 503 sometimes? Intermittent 503s are almost always pool exhaustion, a rate limit, or one unhealthy node in a load-balanced pool — not the application as a whole.

Should my maintenance page return 503 or 200? 503. Returning 200 tells search engines your maintenance notice is your real content, which is far more damaging than the outage itself.