shadcn.io is not affiliated with official shadcn/ui
Request Timeout Error Block for React
A full-height 408 page for a report generator: a request waterfall on a fixed time axis with a cut line at the wait you choose, a verdict that says whether the answer would have arrived, and a Retry that names the wait.
Installation
Overview
Show visitors why a request timed out and what a longer wait would do, with this timeout error block for React with Base UI. It's the error screen of Sheetmoor, a report generator: the page's two side rails run its full height, and one band crosses the screen between two rules with a plus mark where each meets a rail. The status code sits at the end of the header as display text, with the heading "The report took too long" and one sentence at the start. A Native Select chooses how long to wait (30, 60 or 120 seconds) beside the Shine Button, the only colored control, which always names the wait: "Retry with 60 s". Under a rule drawn by Guides, the request's waterfall runs across the band on one fixed 0 to 120 second axis: DNS lookup, Connect and TLS handshake are slivers (121 ms in all), and "Waiting for the server" runs to a heavy cut line at the limit you chose. The server's typed answer lands at 42 seconds, so a 30 second wait is cut short, with the rest drawn hatched, while 60 or 120 would have finished. The bars and the verdict redraw with the choice, and the page never changes height. It's built from Native Select, Field, Shine Button and Guides, with CSS only. For the timeout page of any app with slow requests.
FAQ
What does Retry do, and what stays in the page?
Nothing leaves the page. Retry waits under a spinner for under a second and then says what that wait would have done: "Retried with a 60 s wait: finished at 42 s", or "cut again at 30 s". The outcome is fixed by the wait you chose, not by luck, and the line says the answer is typed and nothing was requested. To wire it for real, re-run the report with the chosen timeout where the code says so, and draw the waterfall from the timings you measure.
Where do the timings come from?
They're typed constants: STEPS for the three connection steps, RESPONSE for when the server's answer lands and AXIS for the track's width. Every bar, the cut line and both sentences derive from them, so they always agree. In your app, take them from the browser's Resource Timing entries or your server's trace, and keep the axis fixed so a longer wait is a visible move of the cut line, not a rescaling.
Why are the first three bars so thin?
Because they are: 121 ms against a 120 second axis is a tenth of a percent. That is the point of the picture: the connection is fine, and the time goes on waiting for the server. Each bar keeps a three pixel minimum so it never disappears, and its duration is written beside its name.
Is 408 the right status for this?
Strictly, 408 means the server gave up waiting for the client's request, while a slow answer behind a gateway is usually a 504 (gateway timeout) or a client-side timeout. Use the status your server really returns, and set it in the response: a component can't. Call the page what it is for the visitor: the request took too long.
Is it usable with a keyboard and a screen reader?
The select has a real label and works with the keyboard like any select; the waterfall is a labelled figure with a list, so a screen reader reads each step with its duration, and the last row says "30 s, cut" or "42 s". The verdict is a polite status line, and after Retry, focus moves to it. The cut is a heavy line and the hatched part is a pattern, never only a color.
Related
- Pro
500 Server Error
Server and outagesA full-height 500 page for an event-ticketing site: the heading, a copyable reference and time, a Try again that honestly keeps failing, and a framed figure of the request's path with the failed stop marked.
- Pro
Error Troubleshooting Steps
Help and supportA full-height error page for a video-call app that walks you through four fixes: a Try again that honestly keeps failing, ticked steps each with a why and a How, a four-part bar, and a Still stuck note that switches on when all four are ticked.
- Pro
Error Debug Logs Window
In-app errorsA debug-log viewer for an API monitoring tool, as a fixed-height app window: a Critical badge and copyable error id, a level filter with counts, eight log lines with the failing one marked, and a foot that copies, downloads and reports.
- Pro
Server Error Incident Card
Server and outagesA server-error panel for a studio-booking app: a card of what the page knows (error type, time, a copyable request id, retries) and what you can do, with a Retry that adds a typed retry and keeps failing.
- Pro
Error Feedback Form
Help and supportA full-height error page for a document-export tool that asks what you were trying to do: quick-pick chips that start the message, a checked message and optional email, and a thank-you that replaces the form in place.
- Pro
Rate Limit Error
Blocked and limitedA full-screen 429 for an API key over its limit: a 10 by 10 grid of the last 60 seconds of requests, the Retry-After header worked out from the oldest, and a demo clock that empties the oldest cells so Retry works.