shadcn.io is not affiliated with official shadcn/ui
500 Server Error Block for React
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.
Installation
Overview
Tell visitors the truth when your server fails, with this 500 error page for React with Base UI. It's the error screen of Admitwell, an event-ticketing site: 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. At the start sit the status code as display text, the heading "Something went wrong on our side", one sentence that says it wasn't the visitor, the two things the page knows (a reference with a Copy Button and the time in UTC) and the way forward: a Shine Button "Try again", an outline Button back home and a status link. At the end a framed figure, ruled by Guides, draws the path the request took: You, Edge, App and Database, with the third stop in a dashed ring, marked with a Status dot and the words "Failed here", and the fourth drawn dashed because it was never reached. Try again waits for a moment and then says plainly that the page is still failing, and the page never changes height. It's built from Shine Button, Button, Copy Button, Status and Guides, with a CSS entrance only. For any app's server error page.
FAQ
What does Try again do, and what stays in the page?
Nothing leaves the page. Pressing Try again shows a spinner on the button for under a second, then a polite status line says "Still failing, attempt 1" and that this demo page always fails; each press counts one more. It never succeeds by accident, because a demo that fixed itself would teach the wrong thing. To wire it for real, retry the request your page failed on (re-fetch the data, or refresh the route) where the code says so, keep the busy state until it answers, and show the page again when it succeeds.
Does this return a 500 status to browsers and search engines?
No: a component can't. Send the real HTTP status from your server or framework, so crawlers and monitors see a 500 and not a 200 with an error drawn on it. In Next.js that is your route's error boundary or a thrown error in a server component; in any other stack, set the response status where you render this page.
Why doesn't the page say it is being fixed?
Because nothing in the page knows that. A line like "we've been notified" is a promise a block can't keep, so the copy says only what is true: it's on our side, it wasn't the visitor, and here is the reference to quote if they write in. If your monitoring really does page someone on a 500, you can say so in the sentence under the heading.
Where does the reference come from?
It's the constant REFERENCE, fixed so the block reads the same on the server and in every browser. In your app, generate one per failure (a request id from your logs or error tracker), show it here and log it with the stack trace, so the visitor's message can be matched to the failure. The Copy Button writes the real text to the clipboard and announces "Copied" politely.
How do screen readers and keyboards get through it?
The big "500" is decoration (aria-hidden): the heading and the sentence under it say the same in words, with "Error 500" in the sentence. The path figure is a real ordered list, so a screen reader hears "You, Sent", "Edge, Reached", "App, Failed here", "Database, Not reached"; state is a word and a dashed shape, never only a color. Tab runs Copy, Try again, Go home and Check status, each with a visible focus ring, and after a retry focus moves to the status line so its result is read out.
Where do the Go home and Check status links go?
Both are plain links to #: point them at your home route and your status page. Go home is a Button with render set to an a element and nativeButton={false}. The page never calls history.back(): a visitor who arrived from a bookmark has no history to go back to.
Related
- 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
Error Support Channels
Help and supportA full-height error page for a handmade-goods marketplace that sends you to a person: three channels with their real cost in time, and a composer whose heading and button follow the channel and that attaches the error details.
- 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
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
Planned Maintenance Progress Error
MaintenanceA full-height maintenance page for an online bank that shows a five-segment progress bar with the window's start and expected return, and a Check again button that reports a typed result.