~/tools / 04 / http-status-404-500
HTTP Status Code Simulator
Happy paths are easy; the 3 a.m. pager fires on the unhappy ones. Simulate the exact failure modes your retry logic, error boundaries, and alerting must survive: a clean 404 with a request ID for tracing, a 500 with an opaque incident reference, or a 429 that ships a Retry-After header your backoff code should respect.
— validating —
$ man status-codes
Everything above is encoded into the #data= fragment of the exported URL — deflated and base64url-packed by your browser. Fragments are never sent to any server, so this mock is shareable and private. Paste the URL anywhere: a teammate's browser decodes it identically.
cat ./tldr.txt
An HTTP status code simulator returns a chosen status — 404, 500, 429, or any code you set — with a realistic JSON error body and matching headers such as Retry-After, so retry logic, error boundaries, and alerting can be exercised on demand.
./when-to-use-this
- Your exponential backoff reads Retry-After and you need a 429 that actually carries the header to confirm it waits the right amount.
- A React error boundary has never been rendered in development because the API never fails locally.
- You need to confirm a request id from a 500 response surfaces in your logs and support tooling.
./frequently-asked
- Does the page actually return the HTTP status I choose?
- No, and this is the key limitation. A static page cannot control its own response status, so the interceptor renders the status line, headers, and body visually rather than serving them at the protocol level. Use it to design and share error contracts; use a local proxy or mock server when code must branch on a real status code.
- Which status codes are supported?
- Any code from 100 to 599. Common ones are labelled automatically with their standard reason phrase — 404 Not Found, 429 Too Many Requests, 503 Service Unavailable — and the status line is colour-coded by class so 4xx and 5xx are distinguishable at a glance.
- What should a good API error body contain?
- The templates follow the widely adopted convention: a stable machine-readable code, a human-readable message, and a request id that ties the response to a server-side log entry. Rate limit responses add Retry-After plus the X-RateLimit family so clients can back off precisely rather than guessing.