500 error page with incident tracking

A generic 500 response gives users no information about whether the problem is transient or permanent, no way to report what happened, and no confidence that anyone knows the system is broken. CWE-209 warns against exposing internal error details, but the opposite failure — showing nothing at all — is equally problematic for recoverability. ISO 25010 reliability.recoverability requires the system to restore or redirect to a usable state; a 500 page with no retry and no incident ID achieves neither. An incident ID on the error page links user-reported failures to server-side logs without requiring users to paste stack traces.

In Next.js App Router, app/error.tsx doubles as the 500 page for server component errors. Surface error.digest as the incident ID — Next.js generates this automatically and logs the correlation server-side.

// app/error.tsx
'use client'
export default function ServerError({
  error,
  reset,
}: {
  error: Error & { digest?: string }
  reset: () => void
}) {
  return (
    <main style={{ textAlign: 'center', padding: '4rem' }}>
      <h1>Something went wrong</h1>
      <p>Our team has been notified. Try again or contact support.</p>
      {error.digest && <code>Incident ID: {error.digest}</code>}
      <button onClick={reset}>Try again</button>
    </main>
  )
}

Link the support contact to your actual support channel — mailto:support@yourdomain.com or a help URL — not a placeholder.