Error Boundary Pattern

Contain a render failure to the part of the screen that broke.

involved Developer Experience

What it adds

Failure containment placed at deliberate points in the interface, each with its own fallback and recovery path.

What your agent is told to do

1
Choose the containment points deliberately: the route level, each independently useful region of a page, and any widget rendering data the app does not control. Everything between those points inherits its nearest boundary.
2
Give each boundary a fallback sized and shaped like the thing it replaced, so a failed sidebar widget leaves a widget-shaped message rather than collapsing the layout around it.
3
Offer a recovery that is proportionate to the failure — retry this region, go back to the previous screen, or reload — and never leave a dead panel with no way forward.
4
Send the failure to the app's existing error reporting with enough context to locate it: the boundary's name, the route, and the record type. Not the record contents.
5
Rendering failures are this feature's concern; a request that returns an error is Async Boundary Component's concern. Do not route failed responses through here, because a handled server error is not an exceptional condition and does not deserve a crash fallback.

Edge cases it handles

A single boundary wrapped around the whole application turns every small fault into a blank page. Place boundaries low enough that the navigation, the header, and the unaffected regions all survive.
A boundary that has caught an error stays caught until it is told otherwise, so it must reset when the route or the record it was rendering changes. Otherwise the user navigates somewhere healthy and still sees the old failure.
Reports must carry enough to debug and nothing more. Serialising the failed component's props will send record contents, tokens, and personal data to a third-party service.
Navigation must keep working. If the fallback replaces the region that contained the only way out, the user is stranded and their only option is the browser's back button.
An error thrown inside the fallback itself will loop. Keep fallbacks trivial: static text, one or two controls, no data access.
Failures during an initial server render behave differently from failures after the page is interactive, and the boundary must produce a sensible result in both rather than only the one that was tested.
Repeated automatic retries of a deterministic failure will spin. Cap the attempts and then require an explicit action from the user.

Definition of done

Boundaries exist at the route level and around each independently useful region, not only at the application root.
A caught failure leaves navigation and the rest of the page usable.
Each fallback offers a recovery path and occupies roughly the space of the content it replaced.
A route or record change resets a boundary that had previously caught an error.
Reports include boundary, route, and context, and contain no props, record data, or credentials.
Fallbacks cannot themselves throw, and automatic retries are capped.
Failed requests are handled by Async Boundary Component and do not surface as crash fallbacks.
The feature matches the existing design system.
No existing functionality is broken.

Related features

AI Cost Budgets

Multi-Model Routing

SEO Setup

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.