Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Error Reporting Settings Block for React

An error grouping panel that leads with a tester: paste an error message and it says whether the rules would drop it, group it under a named group or start a new one, beside tabs of grouping rules, ignore patterns and sample rates.

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 where an error would go before the rules ship, with this error reporting panel for React with Base UI. Inside a hairline frame with a plus mark on each corner, the first band is a tester: an Input takes an error message, four sample buttons fill it, and a verdict box says what the rules below would do with it, as they stand now, saved or not. An ignore pattern that matches drops it ("Dropped by the ignore pattern"), otherwise the first grouping rule that matches files it under a named group ("Grouped under Undefined list in CartList, by rule 2"), otherwise it would start a new group. Under it, Tabs hold the grouping rules, the ignore patterns and the sample rate for each environment. Every rule has a Switch, its group or reason, its pattern and how many events it caught this week; Move up and Move down change which grouping rule is first; a Slider sets how many of an environment's events are kept and works out the number a day. The last band counts unsaved changes in a status line beside a Shine Button to save them and an outline Button to discard them. On a phone the tabs scroll with the page and the foot stays pinned to the bottom of the screen. It's built from Input, Tabs, Switch, Slider, Button, Shine Button and Guides, with a CSS entrance only. For error trackers, log tools and any rule list you want to test before you trust.

FAQ

How is a message judged?

First the ignore patterns that are switched on: if any pattern is contained in the message, it is dropped and the verdict names the pattern and the reason. Then the grouping rules that are switched on, from the top: the first whose pattern the message contains files it under that rule's group, and the verdict says which rule it was by its place in the list. If nothing matches it would start a new group. Matching ignores case, and a star in a pattern stands for any run of characters, so "Loading chunk * failed" matches "Loading chunk 482 failed".

Does the verdict follow the unsaved rules?

Yes: the tester reads the rules as they are on the page, so switching a rule off or moving one up changes the verdict at once, before anything is saved. A few moments after you stop typing, or after a change that alters the verdict, the status line says it too, so a screen reader hears the result once instead of on every key. Pressing Enter in the tester tries the message without saving.

How do I fill it with my own rules?

Edit the constants at the top. GROUP_RULES and IGNORE_RULES list the rules (an id, the group or reason in name, a pattern and the week's count), ENVIRONMENTS the environments with the events they send in a day, and SAMPLES the buttons that fill the tester. SAVED holds the order and the switches the account has stored, and the sample rates. Counts are shown as typed; take them from your own stats.

What stays local, and how do I wire it for real?

All of it: no error is received or dropped, the counts are typed, and Save keeps the rules in this page and says so. To make it real, send the ordered rules and rates to your ingest service when saving, run its own grouping on the tester's message (or the same function on the server), and take the weekly counts from its stats.

Is it usable with a keyboard and a screen reader?

Yes. The tester's field is named and describes itself with the verdict, the sample buttons are real buttons, each rule has a named switch, and Move up and Move down are real buttons named for the rule ("Move Slow upstream down"), with the first rule's Up button and the last rule's Down button staying focusable but saying there is nowhere to go. After a move, focus stays on the button you pressed. The tabs follow the arrow keys.

How does it look on a phone?

The tester's field and samples stack at full width and the verdict box reserves its room. The three tabs share the width, and all their panels are as tall as the tallest, so changing tabs never moves the foot, which stays pinned to the bottom of the screen. A long pattern wraps rather than scrolls.

  • Pro

    Errors per hour as a row of 24 selectable columns with a line at 60 an hour, the chosen hour's six error groups ranked by count with a Mute and Undo for each, and a sample stack trace for the group you pick.

  • Pro

    Alert Rules Settings

    Alerts and audit

    An alert rules panel where each rule is a sentence you edit in place with menus and a number field, beside a framed chart of its metric with the threshold line and a computed count of how often it would have fired.

  • Pro

    Developer Tools Settings

    API and webhooks

    Four SDK switches and an environment choice beside a request panel they steer: capture lists six requests, choosing one opens its JSON, and debug, verbose errors and timing each add their own part to what it shows.

  • Pro

    Audit Log Settings

    Alerts and audit

    A settings change history in a fixed-height window: changes grouped by area in folds with counts, an actor filter, and a detail pane with the before and after values, who and when, and a Revert that undoes only the latest change to a setting, marks the original and adds a revert event at the top.

  • Pro

    An escalation policy on a vertical rail whose axis is the clock: tiers with a target, a channel group and a timeout, cumulative minutes on every node, add, move and remove, and a re-page switch.

  • Pro

    A destinations window for alerts: a rail of Slack, email, PagerDuty, webhook and SMS destinations with a status word, beside the chosen one's routing by severity, a pause switch and a simulated test.