A 503 is a different kind of failure from a timeout or a refused connection. The server is there, and it answered. What it said is that it cannot handle the request at the moment. The HTTP standard describes 503 as a temporary condition, typically overload or scheduled maintenance, and allows the server to say when to try again.

That "temporary" is a promise the server makes, not a guarantee. This guide helps you find out which kind of 503 you have and what to look at first.

What the response tells you

Something produced the 503 response. It may be the application, the web server, a load balancer, a proxy, or a content delivery network (CDN). That already narrows things: the network path and DNS are working, because the answer reached you.

Two clues are worth reading before you log in anywhere:

  • The page itself. A plain message from the web server, a branded maintenance page, and a CDN error page each point to a different layer.
  • The headers. Look for a Retry-After header, which says how many seconds to wait or gives a date. A server that sends it is usually telling you the 503 is intended, for example during maintenance. Headers that name a proxy or CDN show which layer answered.

The three common causes

Cause What it looks like First thing to check
Planned maintenance A maintenance page, often with Retry-After; started at a known time Whether a deployment, migration, or maintenance mode was switched on
Overload Slow responses first, then 503; worse at busy hours CPU, memory, and the limit on simultaneous workers or connections
Backend marked unavailable A proxy or load balancer answers 503 while the application behind it is down or failing its health check The health of the application behind the proxy, and the proxy's own error log

Some services also answer 503 on purpose when a client sends too many requests, instead of the more usual 429. If you rate limit visitors, check whether the limit is catching your own traffic.

Check from the outside first

Before you change anything, see what a visitor sees. From any machine:

curl -sS -o /dev/null -D - https://example.com/

This prints the status line and headers. To see how long the request took and what status came back in one line:

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/

Run it a few times. If it returns 503 every time, the condition is steady. If it alternates between 200 and 503, one of several servers behind a load balancer is probably unhealthy, or workers are running out intermittently. Also ask someone on a different network to try, to rule out an answer that depends on where you are.

Work from the front to the back

Follow the request in the order it travels:

  1. CDN or proxy in front. Is it the one answering? Check its status page and its own error log. A CDN that cannot reach your server often shows its own error page.
  2. Load balancer. Does it list all backends as healthy? A backend that fails its health check is removed, and with none left the load balancer returns 503.
  3. Web server and application workers. Are there free workers? A pool that is full leaves new requests waiting, and some setups answer 503 when the queue is full. Look for log lines about reaching a limit.
  4. Application and its dependencies. A database that is full or unreachable can make the application refuse work. So can a downstream service the page depends on.
  5. Recent changes. A deployment, a configuration change, a plugin update, or a traffic spike shortly before the first 503 is the most common explanation. Start your timeline there.

Read the pattern

The timing says as much as the response:

  • A burst of 503s at the time of a deployment is usually the restart itself. Fix it by changing how you deploy, not by chasing the error.
  • 503 at the same hour every day points to a scheduled job, a backup, or a traffic peak that exhausts resources.
  • 503 that follows rising response times points to overload. Response time often climbs for minutes before the first 503. See response time.
  • 503 from one visitor only may be a rate limit, a blocked address, or a security rule, not an outage.

What a monitor can tell you

A monitor that requests your address from the outside cannot see inside the server, but it gives you the timeline you need.

UptimeWire counts any final answer outside 200 to 399 as a failure, so a 503 is a failure. A failed check is repeated, and an incident opens after three failed checks in a row, about 20 seconds apart. The reason is recorded, for example "HTTP 503", with when it started and how long it lasted. See monitoring incidents.

This helps in practice: you can see whether the 503 was a short burst or a long outage, and whether it came at a pattern of times. It does not tell you the cause. UptimeWire does not look inside your application or measure your server.

For planned work, UptimeWire’s planned maintenance holds incident alerts while the work is under way. If a short 503 during every deployment keeps raising alerts, see why uptime monitors send false alerts.

Checklist

  • Is the 503 steady or intermittent? Test several times.
  • What answered: application, web server, proxy, load balancer, or CDN?
  • Is there a Retry-After header, and does it say when to try again?
  • Did a deployment, change, or traffic spike come just before it?
  • Did response time rise before the first 503?
  • Are all backends healthy, and are there free workers?
  • Does the failure follow a schedule?

When a 503 is the right answer

A 503 during real maintenance is correct behaviour. It tells visitors and search engines to come back, which a 200 page that says "down for maintenance" does not. If you plan downtime, answer 503 on purpose and, where you can, include Retry-After. What matters is that the 503 ends when the work does.