Skip to content
shadcn.io

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.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

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.

How does it look on a phone?

The code moves above the heading, the select and the button stack full width, and the waterfall keeps its axis with each label above its bar, so nothing needs to scroll sideways. Retry is on the first screen.

  • Pro

    500 Server Error

    Server and outages

    A 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

    A 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

    A 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 outages

    A 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 support

    A 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 limited

    A 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.