HTTP 503 — Service Unavailable
HTTP 503 is the planned outage signal: the service is temporarily overwhelmed or down for maintenance and will return. Retry-After is the courtesy header that turns a wall of retries into a orderly backoff.
When 503 shows up
- Maintenance windows and deploys draining traffic.
- Overloaded services shedding load with a polite come-back-later.
Mocking a 503 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/data",
"status": 503,
"delay": 250,
"enabled": true,
"body": {
"error": "service_unavailable",
"retryAfter": 60
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 503 mean?
The service is temporarily unable to handle requests. Retry after the interval in Retry-After; the outage is expected to be transient.
How can I test a 503 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 503. The example configuration above returns this response after the listed delay, so the client exercises its 503 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.