The short version
- 01Check the service's status page and any maintenance message before retrying.
- 02Respect Retry-After when the response gives an estimated waiting period.
- 03Confirm a submitted action's result before repeating a payment or other write.
- 04Inspect server metrics and recent deployments when you operate the affected service.
- 05Check load-balancer targets and routing when the application is not receiving requests.
- 06Verify recovery through the public URL and remove stale cached outage responses when necessary.
Raw message
503 Service Unavailable
Likely causes
- Scheduled maintenance or a deployment temporarily stopping service.
- Overload exhausting application capacity or connection limits.
- A load balancer with no usable targets for the request.
- An intermediary continuing to serve a cached outage response after recovery.
What a temporary server failure tells you
503 indicates that the service cannot currently fulfil the request, commonly because of overload or maintenance. The temporary meaning does not guarantee a particular recovery time. The response may come from infrastructure in front of the application.
Keep 429 and 503 distinct: the first reports request-rate limiting, while the second reports service unavailability. Read the body and provider details rather than applying the same fix to every 5xx number.
If you are visiting the site
Check the provider's status page or maintenance notice. If Retry-After is present, wait for its delay or date before a permitted retry. A server-side capacity failure is not normally repaired by changing your browser password or erasing local browsing data.
If the error followed a payment, booking or form submission, check the resulting record or confirmation before repeating the action. This is a precaution for an uncertain outcome: HTTP warns against automatically retrying non-idempotent requests without knowing they are safe to repeat or were never applied.
If you operate the service
Identify the component producing the response, then compare the failure time with maintenance, deployments and capacity metrics. Application overload can involve CPU, memory or connection pools. Check evidence before raising limits or restarting every component; a restart alone may not remove the load.
On AWS Application Load Balancers, a documented 503 cause is a target group with no registered targets or all targets unused. With target optimizer enabled, rejection can also mean no targets are ready. Check registration, routing and target state for that specific platform instead of assuming every 503 is an application crash.
After recovery, request the public URL through the normal serving path. Review cache headers and any cached outage page so visitors receive restored content. During a real outage, preserve a truthful server-error response; Google's crawlers treat temporary server failures differently from deleted content.
Sources and review notes
Checked on . Based on HTTP semantics, MDN, AWS and Google documentation. AWS is an infrastructure example. The owner checklist is diagnostic guidance, not a claim that every 503 has the same cause.