HTTP 503 Service Unavailable

HTTP 503 Service Unavailable indicates the server (or an upstream dependency) failed to fulfill a valid request. Treat it as a reliability signal: capture evidence, attribute the failure, and apply safe retry and backoff based on idempotency.

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

curl -i "https://httpstatus.com/api/status/503"
Try in playground

Meaning

The server is currently unavailable (overloaded, down for maintenance, or rate limiting). Should include Retry-After header when possible.

What it guarantees
  • The server (or an upstream) failed to fulfill a valid request.
  • The service is temporarily unavailable or overloaded.
What it does NOT guarantee
  • The failure is permanent.
  • Immediate retries are always safe or effective.

When to use this status

  • Planned maintenance where clients should retry later.
  • Overload shedding to preserve core capacity.
  • Dependency outages preventing temporary service.

When NOT to use this status (common misuses)

Returning 5xx for client validation errors.
Clients retry unnecessarily; traffic spikes and costs increase.
Returning 500 without stable error identifiers/correlation.
SRE triage slows down; alerting becomes noisy and hard to act on.
Returning 503/504 without retry guidance.
Clients hammer the service or give up too early; cascading failures worsen.

Critical headers that matter

Content-Type
Defines error body format (JSON/text/problem+json).
Clients can’t parse structured errors; observability loses fidelity.
Cache-Control
Prevents caching transient errors unless intended.
CDNs cache failures; prolonged user-visible outages.
Retry-After
Signals expected recovery window.
Clients hammer the service during maintenance/incidents.

Tool interpretation

Browsers
Displays an error state; devtools exposes status and headers. Cache headers can accidentally cache error documents.
API clients
Classifies as failure; retry policy depends on idempotency and code class. Structured errors improve handling.
Crawlers / SEO tools
Persistent failures reduce crawl rate; soft-404 patterns cause indexing instability.
Uptime monitors
Typically alerts based on rate/threshold. Consistent classification reduces false positives.
CDNs / reverse proxies
May cache errors if misconfigured; respects Cache-Control and can serve stale on origin failure.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
  • Error cacheability and retry guidance signals
Correctness warnings
  • Missing Retry-After makes safe backoff harder for clients.

Guided Lab outcome

  • Reproduce HTTP 503 Service Unavailable using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
  • Learn to attribute failures to origin vs upstream and apply safe retry/backoff decisions.

FAQ

Should clients retry on HTTP 503?
Often yes for idempotent requests with backoff. Avoid blind retries for non-idempotent writes.
Is HTTP 503 cacheable?
Generally should not be cached unless explicitly intended; use Cache-Control to prevent sticky failures.
Which headers matter most for HTTP 503?
Content-Type and Cache-Control are the baseline. Some codes also require Location, WWW-Authenticate, or Retry-After.
How does this affect monitoring?
Server errors typically page based on rate/threshold; enrich with upstream attribution.
How does this affect crawlers/SEO?
Sustained 5xx reduces crawl rate and can drop pages from index.
What should error responses include?
A stable, machine-parseable format with correlation IDs and actionable messages.

Client expectation contract

Client can assume
  • The server or an upstream failed to fulfill the request.
Client must NOT assume
  • Immediate retries are always safe or effective.
Retry behavior
Retry after Retry-After (if present) with exponential backoff; consider circuit breaking.
Monitoring classification
Server error
Alert on rate and duration; ensure CDNs do not cache transient failures.

Related status codes

502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the upstream server.
504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
429 Too Many Requests
The user has sent too many requests in a given amount of time.

Explore more

Related guides
Related tools
Related utilities