Error boundaries exist around high-risk feature sections

A root error boundary keeps the shell alive, but without feature-level boundaries a single crashing widget still takes down the entire dashboard, settings panel, or payment form. ISO 25010 reliability.fault-tolerance expects fault isolation: one failed revenue widget should not blank the user analytics widget beside it. Applications with data tables, real-time feeds, and payment forms are the highest-risk areas — each independently capable of crashing a page and forcing the user to reload and start over.

Wrap each high-risk feature section in its own ErrorBoundary. In Next.js App Router, add error.tsx files inside each route segment directory; in other apps, use react-error-boundary at the component level.

// app/dashboard/error.tsx — dashboard-scoped boundary
'use client'
export default function DashboardError({
  reset,
}: {
  reset: () => void
}) {
  return (
    <div>
      <p>Dashboard failed to load.</p>
      <button onClick={reset}>Retry</button>
    </div>
  )
}

Target at minimum: dashboard, checkout/payment form, and any real-time feed — these three account for the highest crash frequency in vibe-coded apps.

• ID: error-resilience.error-boundaries-ui-recovery.feature-error-boundaries

• Severity: critical

• What to look for: Count all major feature areas (dashboard, settings, forms, data tables). Enumerate which have dedicated error boundaries vs. which rely solely on the root boundary. Look for error boundaries wrapping high-risk sections: dashboard widgets, form panels, real-time feeds, data tables, payment forms, or any section that could crash the whole page. Search component files for error boundary usage beyond the root level.

• Pass criteria: At least 3 distinct high-risk feature areas are wrapped in error boundaries that render localized fallbacks (not app-wide). At least 50% of major feature areas should have dedicated error boundaries.

• Fail criteria: No feature-level error boundaries found, or only the root error boundary exists with no feature-level coverage.

• Skip (N/A) when: The application has no complex features or only simple static pages with no interactive components.

• Cross-reference: For root error boundary, see root-error-boundary. For data fetching error states, see data-fetching-states.

• Detail on fail: Name the high-risk areas that lack error boundaries. Example: "Dashboard widgets, form panels, and data tables have no error boundaries — one component crash takes down the entire feature" or "Only 1 feature (payment form) has an error boundary; checkout process, user dashboard, and profile page unprotected"

• Remediation: Wrap feature sections in error boundaries to prevent one feature from crashing the entire page:

  // app/dashboard/error.tsx — feature-level error boundary
  'use client'
  export default function DashboardError({ error, reset }: { error: Error; reset: () => void }) {
    return <div>Dashboard failed to load. <button onClick={reset}>Retry</button></div>
  }
  

  // components/Dashboard.tsx
  import { ErrorBoundary } from 'react-error-boundary'
  
  function WidgetError({ error, resetErrorBoundary }) {
    return (
      <div>
        <p>This widget encountered an error: {error.message}</p>
        <button onClick={resetErrorBoundary}>Try again</button>
      </div>
    )
  }
  
  export function Dashboard() {
    return (
      <>
        <ErrorBoundary FallbackComponent={WidgetError}>
          <RevenueWidget />
        </ErrorBoundary>
        <ErrorBoundary FallbackComponent={WidgetError}>
          <UserActivityWidget />
        </ErrorBoundary>
      </>
    )
  }