Show a Safe Fallback for Next.js App Router Server Component Errors

If an App Router Server Component throws unexpectedly while rendering, put an error.tsx file in the route segment whose page it should protect. Next.js uses that file as an error boundary: instead of leaving the failed page UI on screen, it renders your fallback. Keep the fallback useful to the visitor, but keep server error details out of it.

This is for unexpected rendering failures, not every unsuccessful operation. For an expected data-fetching outcome, a Server Component can inspect the response and render an appropriate message or redirect. Errors in event handlers and asynchronous work that runs after rendering need their own handling; a rendering error boundary will not catch them. See the App Router error-handling guidance for that distinction.

Put the fallback beside the products page

Suppose the products page cannot finish rendering because of an unexpected exception. This deliberately small example throws every time, making the boundary relationship clear; it is not a model for ordinary missing-product handling.

app/products/page.tsx:

export default function ProductsPage() {
  throw new Error('Product rendering failed: internal detail')
}

Add the matching boundary at app/products/error.tsx. Unlike the page above, the error component must be a Client Component, so the file starts with 'use client'. Next.js passes it an error and a reset function. The type includes the error prop even though this fallback deliberately does not display it.

'use client'

type ProductsErrorProps = {
  error: Error & { digest?: string }
  reset: () => void
}

export default function ProductsError({ reset }: ProductsErrorProps) {
  return (
    <section role="alert">
      <h2>Products are unavailable right now</h2>
      <p>We couldn’t show this page. Please try again.</p>
      <button type="button" onClick={() => reset()}>
        Try again
      </button>
    </section>
  )
}

For this example, the exception in app/products/page.tsx falls within the app/products/error.tsx boundary, so the products fallback replaces the failed page tree. The button calls reset(), which tries to render the boundary’s contents again. If the problem was temporary and rendering succeeds, the page can replace the fallback. Here the page throws on every attempt, so retrying cannot fix it; the fallback can remain visible. The Next.js error-file reference documents the Client Component requirement and the error prop.

Keep the server error out of the UI

Do not put error.message, a stack trace, or a digest in the paragraph shown to visitors. The generic copy above tells them what they can do without trying to turn an exception into a public diagnosis.

For a Server Component error in production, Next.js forwards a generic message and an automatically generated digest rather than the original, potentially sensitive message. The digest is an identifier you can use to match the failure to corresponding server-side logs—not an explanation for the visitor and not a recovery mechanism. During development, the forwarded error can include the original message to help debugging, which is another reason not to make error.message part of the fallback’s user-facing design. The Next.js 14 App Router documentation describes this production-versus-development behavior.

Check what the boundary actually wraps

Boundary placement matters when the exception is not in the page. A segment’s error.tsx can catch failures in its page and nested children, but not in that same segment’s layout or template. If app/products/layout.tsx or app/products/template.tsx throws, move the relevant fallback responsibility to a parent segment’s error boundary instead; errors bubble to the nearest parent boundary.

The root layout or template has no parent segment boundary to catch it. For those failures, use app/global-error.tsx. Its fallback replaces the root view, so it must supply its own <html> and <body> tags. That is a different job from the products fallback, which is meant to contain a failed products page while leaving its surrounding layout in place. The App Router error-file reference covers the root-level convention.