Sitelet https://funapi.dev/status/408

HTTP 408 Request Timeout

The server gave up waiting for the client to finish sending the request, and has closed (or will close) the connection.

Defined in RFC 9110 §15.5.9 — 408 Request Timeout · MDN reference

Where you meet HTTP 408 in production

Idle keep-alive connections that a server or load balancer closes, slow mobile uploads, and clients that open a connection and never send. Browsers often retry silently after one.

Why you would test it

Simulates a slow or stalled upload. The thing to test is whether your client retries automatically — for an idempotent request it may, for a POST it must not without an idempotency key.

What your client should do about a 408

A 408 means the request was not processed, so retrying is generally safe — the server says it did not act on it. Retry on a fresh connection. If it recurs, the problem is upload speed or a client that stalls mid-body.

408 versus the codes it gets confused with

Endpoints that return 408

1 endpoint in this playground answers with 408. Every one is free, needs no signup, and can be called from the browser or with curl.

Questions about HTTP 408

Is it safe to retry a 408?
Generally yes — the server is stating it did not process the request. Retry on a new connection.
Why do I see 408 without sending anything?
Some servers send it when they close an idle keep-alive connection, so a client that reuses that connection reads a 408 it did not cause.

Other client error codes

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated