Next.js error.tsx: Build a Support Handoff for App Router Errors

Next.js error.tsx: Build a Support Handoff for App Router Errors

Next.js App Router gives teams a powerful primitive: error.tsx.

Most teams use it like this:

'use client';

export default function Error({ reset }: { reset: () => void }) {
  return (
    <div>
      <h2>Something went wrong</h2>
      <button onClick={() => reset()}>Try again</button>
    </div>
  );
}

That is a start, but it is not enough for a SaaS product.

If a customer hits an error in checkout, onboarding, or an integration flow, the fallback should not only say "try again." It should help the user recover and give support enough context to act.

The official Next.js docs explain that error.js automatically creates a React Error Boundary for a route segment, keeps layouts above the boundary interactive, and can expose reset() so users can try to recover without a full reload: Next.js App Router error handling.

That makes error.tsx a natural place to build a support handoff.

Why generic error.tsx pages create tickets

A generic fallback tells the user almost nothing:

• Did my payment go through?
• Did my settings save?
• Should I refresh?
• Is this my browser?
• Should I contact support?
• What should I tell support?

When the UI does not answer those questions, the user creates a ticket.

That ticket often says:

The billing page crashed when I tried to upgrade.

Support still needs the actual details:

• route segment
• deployment release
• error digest
• failed request
• account ID
• browser
• user note
• whether retry worked

error.tsx is the moment to capture all of this.

Route-level recovery beats global fallback

Use route-level error.tsx files for workflows that users can retry independently.

Good candidates:

• app/(dashboard)/billing/error.tsx
• app/(dashboard)/integrations/error.tsx
• app/(dashboard)/reports/error.tsx
• app/onboarding/error.tsx
• app/settings/error.tsx

Keep global-error.tsx for severe root failures. The Next.js docs note that global-error.js replaces the root layout when active, while route-level errors allow parent layouts to stay visible.

For support outcomes, that difference matters. If navigation remains available, users can still move, retry, or contact support without feeling trapped.

A support-ready error.tsx example

'use client';

import { useEffect, useState } from 'react';

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

export default function BillingError({ error, reset }: Props) {
  const [eventId, setEventId] = useState<string | null>(null);

  useEffect(() => {
    async function recordError() {
      const response = await fetch('/api/support/error-event', {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify({
          message: error.message,
          digest: error.digest,
          route: '/billing/upgrade',
          projectId: 'billing',
          environment: process.env.NODE_ENV,
        }),
      });

      const data = await response.json();
      setEventId(data.eventId);
    }

    void recordError();
  }, [error]);

  return (
    <section role="alert" aria-live="polite">
      <h2>Checkout paused safely</h2>
      <p>
        We could not load your billing plan, so we stopped before charging you.
        Refresh this step, then try again.
      </p>

      <button onClick={reset}>Try again</button>

      {eventId ? (
        <p>Support event: {eventId}</p>
      ) : null}
    </section>
  );
}

This fallback does four useful things:

1. Explains the product state.
2. Reassures the user about safety.
3. Gives a retry path.
4. Records context for support.

What to send with the support handoff

For each App Router error, capture:

• error.message
• error.digest
• route segment
• release or commit SHA
• environment
• account ID
• user ID, if available
• browser and device
• last safe user action
• user note, if they request help

In production, Next.js strips sensitive details from server component errors and forwards a generic message plus a digest that can be matched to server logs. That digest is useful in support handoffs because it lets engineering connect the customer-facing failure to backend logs without exposing secrets to the browser.

Better recovery copy by route

Use route-specific copy. A billing fallback should not sound like an upload fallback.

Route	Weak copy	Better copy
Billing	Something went wrong	Checkout paused before charging you
Uploads	Upload failed	The file was too large or the connection dropped
Integrations	Could not connect	We could not verify the integration token
Reports	Failed to load	This report timed out while generating
Settings	Error	We could not save changes, so your previous settings are still active

Specificity lowers panic.

Avoid leaking sensitive data

Do not render raw stack traces to users.

Use:

• user-safe explanation
• hidden support event ID
• redacted context
• server-side logs for full stack traces

If users need to contact support, send the context through your backend rather than asking users to copy technical details from the page.

How to measure App Router recovery

Track:

• error events per route
• reset clicks
• successful re-render after reset
• support requests from the fallback
• repeated digests or fingerprints
• affected releases

The metric you want is not "zero errors." It is fewer users abandoning broken flows and fewer mystery tickets reaching support.

How Logwise fits

Logwise can sit beside error.tsx as the recovery and handoff layer. It records the event, explains the failure, tracks recovery feedback, and routes unresolved errors into Slack, Zendesk, Freshdesk, Gleap, or your webhook.

Start with the Logwise docs if you want the current implementation path.

Bottom line

Next.js error.tsx is not only an error page. It is a support workflow.

Use it to contain the failure, help the user recover, and give support a clean handoff when the user still needs help.