Segment-specific recovery
A dashboard page or nested route fails during rendering.
Next.js 16+ · Directive
Use a route segment's error.tsx file to catch unexpected runtime failures and render fallback UI. Next.js supplies the error and a reset callback so the boundary can report the failure and retry.
The error.tsx convention provides route-scoped fallback UI for unexpected runtime failures. It must be a Client Component because the fallback can use client-side behavior such as effects and retry actions; the boundary receives the thrown error and a reset callback.
export default function Error({ error, reset }: { error: Error & { digest?: string }; reset: () => void }) { /* fallback UI */ }| Name | Type | Description |
|---|---|---|
error | Error & { digest?: string } | The thrown runtime error passed to the fallback component; it may include a digest for identifying server-side failures. |
reset | () => void | A callback that retries rendering the contents protected by the boundary. |
Fallback React UI rendered when an unexpected runtime error occurs within the protected route segment or its nested children.
// app/dashboard/invoices/error.tsx
'use client'
import { useEffect } from 'react'
export default function Error({
error,
reset,
}: {
error: Error & { digest?: string }
reset: () => void
}) {
useEffect(() => {
console.error(error)
}, [error])
return (
<main>
<h2>Something went wrong!</h2>
<button onClick={() => reset()}>Try again</button>
</main>
)
}Place a client component named error.tsx in a route segment. Next.js uses it as an automatically inserted error boundary for that segment and its descendants; when rendering fails, it receives the error and a reset function so the UI can report the problem and retry.
A dashboard page or nested route fails during rendering.
A user can retry a transient request or rendering failure.
The application needs route-scoped diagnostics and a friendly fallback.
Different parts of a nested application need different recovery boundaries.
Next.js treats error.tsx as a route-segment error boundary and wraps the segment's nested children. If rendering throws within that boundary, the exported component renders as fallback UI and receives error plus reset.
Follow-up: How do you control error granularity? Add error.tsx at the route level where the desired boundary should begin; nested boundaries can isolate more specific failures.
The component must be client-side because the documented pattern uses client behavior, including a retry button and useEffect for logging. The reset callback retries rendering the failed segment.
Follow-up: What should production logging consider? The error object may be sanitized, so use the available digest to correlate the failure with server-side logs.
Errors are handled by the closest applicable boundary in the route hierarchy. Putting error.tsx at different folder levels lets an application choose whether a failure replaces a small portion of a page or a larger route subtree.
Follow-up: How are root-layout failures handled? Use global-error, which can replace the root layout when errors occur there.
global-errornot-foundloadinglayoutReact Error Boundary