HTTP 408 — Request Timeout
HTTP 408 closes the wait: the client took too long to deliver its request and the server gave up on the idle connection. Unlike most 4xx codes, simply resending the request in time may succeed.
When 408 shows up
- Slow clients on flaky networks sending bodies in dribbles.
- Keep-alive connections reactivated after the server already timed them out.
Mocking a 408 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/upload",
"status": 408,
"delay": 1200,
"enabled": true,
"body": {
"error": "request_timeout",
"retry": true
}
}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 408 mean?
The server timed out waiting for the complete request. The request may be retried promptly — the problem was delivery speed, not content.
How can I test a 408 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 408. The example configuration above returns this response after the listed delay, so the client exercises its 408 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.