Confession: I shipped the same bug twice in one week. Both times a React app went white on production, both times I opened Sentry and saw nothing, both times the fix was that my error boundary was in the wrong place. I’ve been writing React for years. I still get this wrong.<\/p>\n
The reason I get it wrong is that “error boundary” sounds like a catch-all safety net, and it isn’t. It catches a very specific kind of error, from a very specific kind of place, and if you don’t set it up carefully your users will see the empty page you thought was impossible. So here’s what I actually ship now: the boundary component I stopped hand-rolling, where I put it, and how I know it’s firing.<\/p>\n
Short version for the impatient: use react-error-boundary<\/a>, wrap boundaries per feature rather than per app, integrate with Suspense on purpose, and pipe errors into Sentry with React’s official docs<\/a> still show a class component. That’s not a bug in the docs. The boundary API relies on That’s fine on paper. In practice I’d copy-paste this thing between projects, forget to add a Here’s the class I used to ship, and it was worse than nothing:<\/p>\n Two problems. There’s no way to reset it without unmounting the whole subtree, and The Here’s the same code, replaced:<\/p>\n Two things that made a real difference. First, This one took me embarrassingly long to internalize. React error boundaries do not<\/strong> catch errors thrown during rendering that happen inside a Suspense boundary while it’s suspending. If you throw a promise (which is how Suspense works under the hood via Every The order matters. I used to slap one boundary at the root of the app and call it done. That’s the version that gives you the “whole app white-screens on a single component’s bug” experience. Now I follow three rules.<\/p>\n At the root, one boundary catches the truly unexpected: a null reference in a shared layout component, a broken import, a runtime version mismatch. Its fallback is a full-page “this page crashed, please reload” screen with a reload button.<\/p>\n Per route, one boundary so a crash in Per risky widget, one boundary. Anything that hits a third-party API, does complex chart rendering, or accepts user-generated markdown gets its own. If the charting library throws, the rest of the settings page still works.<\/p>\n Three levels, chosen deliberately. When I started doing this the number of full-app crashes reported by users dropped to basically zero, and the ones that still happen are almost always shared-layout bugs that deserve a full-page fallback anyway.<\/p>\n The one nuance I wish someone had told me sooner: don’t just pipe every I use Sentry’s React SDK<\/a> with two guardrails. First, I check the error type before capturing:<\/p>\n Second, I set a rate limit on the client-side sample rate for lower-severity errors. Sentry’s own Open the biggest React app you own. Search the codebase for I still get boundary placement wrong sometimes. The last one that bit me was a third-party analytics script throwing inside a memoized child during a render pass, which I hadn’t wrapped because “analytics can’t crash.” It can. Wrap it anyway.<\/p>\n","protected":false},"excerpt":{"rendered":" I broke a React app twice in one week because an error boundary never fired. Here’s the setup I actually ship in 2026 with react-error-boundary and Sentry.<\/p>\n","protected":false},"author":2,"featured_media":454,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"I broke a React app twice in one week because an error boundary never fired. Here's the setup I actually ship in 2026 with react-error-boundary and Sentry.","rank_math_focus_keyword":"react error boundary","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[35],"tags":[505,38,44,41,506],"class_list":["post-455","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development","tag-error-boundaries","tag-frontend","tag-javascript","tag-react","tag-sentry"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/455","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=455"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/455\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/454"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}onError<\/code>. If you want to know why, read on.<\/p>\nWhy the built-in boundary keeps burning me<\/h2>\n
getDerivedStateFromError<\/code> and componentDidCatch<\/code>, and both are class-only. There’s no hook. Not useErrorBoundary<\/code>, not use()<\/code>, nothing. As of React 19 you still have to write a class if you want to roll your own.<\/p>\nreset<\/code> handler, forget to log the error anywhere useful, and end up with a boundary that catches errors and then quietly hides them behind a friendly “something went wrong” message that never gets fixed.<\/p>\nclass ErrorBoundary extends React.Component {\n state = { hasError: false }\n\n static getDerivedStateFromError() {\n return { hasError: true }\n }\n\n componentDidCatch(error, info) {\n console.error(error, info) \/\/ dev-only. useless in prod.\n }\n\n render() {\n if (this.state.hasError) return <p>Something went wrong.<\/p>\n return this.props.children\n }\n}\n<\/code><\/pre>\nconsole.error<\/code> in production is a black hole. If a user hit a bad request that only fires on one route, they’d get a permanent “something went wrong” until they refreshed the tab. I watched this happen in a real session replay and wanted to walk into the sea.<\/p>\nWhat I actually ship now: react-error-boundary<\/h2>\n
react-error-boundary<\/code><\/a> library from Brian Vaughn has been the answer for years, and I don’t know why I resisted it for so long. It gives you an <ErrorBoundary><\/code> component plus a useErrorBoundary<\/code> hook, both of which handle reset properly and take a real onError<\/code> callback for logging.<\/p>\nimport { ErrorBoundary } from "react-error-boundary"\nimport * as Sentry from "@sentry\/react"\n\nfunction Fallback({ error, resetErrorBoundary }) {\n return (\n <div role="alert" className="p-4 border rounded">\n <p className="font-semibold">Something broke loading this section.<\/p>\n <p className="text-sm opacity-70">{error.message}<\/p>\n <button onClick={resetErrorBoundary} className="mt-2 underline">\n Try again\n <\/button>\n <\/div>\n )\n}\n\nexport function FeatureShell({ children }) {\n return (\n <ErrorBoundary\n FallbackComponent={Fallback}\n onError={(error, info) => Sentry.captureException(error, { extra: info })}\n onReset={() => {\n \/\/ clear query cache for this feature, reset local state, etc.\n }}\n >\n {children}\n <\/ErrorBoundary>\n )\n}\n<\/code><\/pre>\nresetErrorBoundary<\/code> is a proper API. I can wire it to a “Try again” button and the boundary re-mounts its children without a full page refresh. Second, onError<\/code> fires on every catch, so I stopped losing errors in production the moment I plugged Sentry into it. That’s most of the value right there.<\/p>\nSuspense boundaries are a different problem entirely<\/h2>\n
use()<\/code> and libraries like React Query), the error propagates up until it either resolves or hits a boundary.<\/p>\n<Suspense><\/code> you add is also a thing that needs a boundary next to it, usually just outside. I cover this pattern in more detail in my post on React Suspense in production<\/a>, but the short version is:<\/p>\n<ErrorBoundary FallbackComponent={Fallback} onError={reportError}>\n <Suspense fallback={<Skeleton \/>}>\n <UserProfile userId={id} \/>\n <\/Suspense>\n<\/ErrorBoundary>\n<\/code><\/pre>\nErrorBoundary<\/code> outside, Suspense<\/code> inside. Get this backwards and a rejected promise from a use()<\/code> hook will kill the fallback UI too, which is somehow worse than not having a fallback at all.<\/p>\nWhere I put boundaries in a real app<\/h2>\n
\/settings<\/code> doesn’t blank out \/dashboard<\/code>. Next.js has this built in via error.tsx<\/code><\/a> files at the route level, which I use verbatim. In React Router you wrap each route element.<\/p>\nHooking up Sentry without the noise<\/h2>\n
onError<\/code> straight into Sentry.captureException<\/code> unfiltered. You will drown in noise from network blips, aborted requests, and React StrictMode double-invocations in development.<\/p>\nonError={(error, info) => {\n \/\/ Ignore aborted fetches; they're not real errors.\n if (error.name === "AbortError") return\n Sentry.captureException(error, {\n contexts: { react: { componentStack: info.componentStack } },\n })\n}}\n<\/code><\/pre>\nErrorBoundary<\/code> wrapper does most of this for you if you use Sentry.ErrorBoundary<\/code> directly instead of the raw library, and I’ve been happy with that on newer projects. But whichever you pick, pass the componentStack<\/code> in explicitly. It’s the difference between a Sentry issue you can debug in five minutes and one you stare at for an hour.<\/p>\nThe one thing to do this week<\/h2>\n
ErrorBoundary<\/code>. Count the results. If it’s one, add three: one at the route level, one around your data-fetching subtree, one around whatever the sketchiest widget is. If it’s zero, install react-error-boundary<\/code>, wire it into Sentry (or whatever error tracker you use; I write about this kind of pipeline work over on my portfolio<\/a>), and ship it before Friday. It takes an hour. You will find at least one silent error the next time you deploy.<\/p>\n