Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Error Support Channels Block for React

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

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

Give visitors a human way out of an error, with this support error block for React with Base UI. It's the error screen of Weftmoor, a marketplace for handmade goods: 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. A start-aligned heading and one sentence sit over three channels on shared hairlines in a frame ruled by Guides: Chat with its typical wait, Email with its reply time and Help centre with how many articles there are. They are real radio cells, one chosen, so arrow keys move between them. Under a rule, the composer: its heading and its Shine Button change with the channel (Start a chat, Write to support, Search the help centre), a Field holds the Textarea for the message, and a Switch attaches the error details, which a Collapsible lists under the button as the reference, the time and the page. Sending checks the message, then says plainly that it only drafted it, and a ghost button starts over. The page never changes height. It's built from Field, Textarea, Switch, Collapsible, Shine Button, Button and Guides, with a CSS entrance only. For the error page of any app with live support.

FAQ

What happens when I send, and what stays in the page?

Nothing leaves the page. The button waits under a spinner for less than a second, then a polite status line says what a real press would do ("Chat drafted. A real one would open now") and that nothing was sent or searched, naming whether the error details were attached; Start over clears the message and returns focus to it. To wire it for real, open your chat widget, post the message and its attachments to your help desk, or run your help-centre search where the code says so, and show its error under the message if it fails.

Where do the times on the channels come from?

They're typed constants (CHAT, EMAIL, HELP), because the block can't know your staffing and never reads the clock. Replace them with your real hours and service levels, and say only what you can keep: a promise like "we reply within 24 hours" belongs on this page only if your team meets it, and a chat that is only staffed on weekdays should say so.

What does Attach the error details do?

It decides whether the reference, the time and the page travel with the message. The disclosure under the button lists the three lines; when the switch is off they're struck through and marked "not attached", and the status line after sending says so. In your app, fill them from the real failure (an id from your error tracker, the request time, the route) and send them with the message, so support doesn't have to ask.

Why is the send button never disabled?

A disabled button can't explain itself, and keyboard users can't reach it. Pressing it with an empty message writes one sentence under the field and moves focus there, which reads the problem out. Typing clears it. The field keeps a line for its problem even when there is none, so a problem never pushes the page.

How does it look on a phone?

The three channels stay in one row, as an icon over a name, and the chosen channel's wait or reply time appears in one line under them; the composer follows with the message, the switch and the send button, which stays on the first screen. The channels' times are still read out by screen readers in each cell.

Is it usable with a keyboard and a screen reader?

The channels are a labelled group of native radio buttons: arrow keys move and choose, Tab leaves the group, and each cell's name includes its time. The switch is a named control, the disclosure's button says whether it's open, and after sending, focus moves to the status line so the result is read out. The chosen channel is shown by a filled dot and a heavier edge, never only a color.

  • 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

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

    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

    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

    Request Timeout Error

    Server and outages

    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.