shadcn.io is not affiliated with official shadcn/ui
Request Timeout Error Block for Svelte
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 Svelte with Ark 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.