error.tsx vs instrumentation.ts: Closing the Coverage Gap

The plain-language idea

It's tempting to treat error.tsx and the instrumentation file's server-error hook as redundant — "we already have error boundaries, why do we also need a monitoring hook?" They actually answer two different questions. error.tsx answers "what does the user see when something breaks?" The server-error hook answers "does anyone on the team find out it broke at all?" A route can nail the first and completely fail the second: the user sees a calm "Something went wrong" screen, clicks away, and the exception that caused it never reaches a dashboard, a Slack alert, or a log anyone reads.

The part that actually needs mapping out is which errors each mechanism sees, because the two coverage areas overlap less than they look like they should:

• A Server Component throwing during render — both fire. The nearest error.tsx up the tree renders a fallback for the user, and the server-error hook independently gets the same error with full request context, because the hook was designed specifically to still fire even when a boundary successfully catches the failure.
• A Route Handler or Server Action throwing — only the server-error hook fires. There's no rendered UI tree for an error boundary to wrap in that case; the request just needs someone told it failed.
• A Client Component throwing during render — only error.tsx fires. React error boundaries work client-side too, so the fallback UI still appears — but this failure never touched your server process, so the server-error hook has nothing to see. This is the real coverage gap: a client-render error is completely invisible to server-side error tracking unless you report it yourself.
• An error thrown in a client event handler, a useEffect, or a rejected promise — neither fires. React error boundaries only catch errors during rendering; they were never designed to catch errors in event handlers or async callbacks. This is the gap most teams don't discover until a user reports "the button did nothing" and there's no error anywhere in any system.

See it in a real thing: closing the client-side gap by hand

// app/dashboard/error.tsx — catches render-phase errors, client or server
"use client";

import { useEffect } from "react";

export default function Error({ error }: { error: Error & { digest?: string } }) {
  useEffect(() => {
    // This is the only place a purely client-side render error
    // gets any chance to reach your monitoring — instrumentation's
    // server hook never sees it.
    reportToMonitoring(error, { source: "error-boundary" });
  }, [error]);

  return <p>Something went wrong loading the dashboard.</p>;
}

// app/dashboard/RevenueChart.tsx — a click handler, not a render
"use client";

export function RevenueChart() {
  return (
    <button
      onClick={async () => {
        try {
          await exportChart();
        } catch (err) {
          // Neither error.tsx nor the server-error hook will ever see this.
          // It's on you to catch it and report it, right here.
          reportToMonitoring(err, { source: "export-click" });
        }
      }}
    >
      Export
    </button>
  );
}

The error.tsx fallback only exists because React re-threw a render-phase error into the nearest boundary — that's the one place client-side reporting is possible without extra wiring. The click handler is a completely different situation: nothing above it is watching, so the try/catch and manual report are the entire error-tracking story for that code path.

What people usually miss

Watch out

• "We have error boundaries" is not the same claim as "we have error tracking." A boundary's entire job is picking a fallback UI; whether anyone gets told about the failure is a separate, optional thing you have to wire up yourself inside it.
• A client-render error never reaches the server-error hook, full stop. It's not a delay or a sampling gap — the hook is scoped to errors the Next.js server process itself captures, and a client-side render never touches that process.
• Event handlers and effects are outside React's error-boundary contract entirely, not a Next.js-specific limitation. This is true of any React app; Next.js's boundary files don't change what a React error boundary can catch.
• Server Actions can fail in two different places with two different visibilities — a thrown error surfaces to the server-error hook always, but if the action's failure also needs to update what the user sees, that's a separate piece of UI state you manage yourself, not something error.tsx picks up automatically for a Server Action specifically.

Why this matters in interviews

"Your team has error boundaries everywhere and users still report bugs support can't find in the logs" is a scenario that tests whether a candidate can name the actual gap — not "add more error boundaries," but recognizing that render-phase boundaries and server-side instrumentation each cover a slice of the failure surface, and event handlers and async callbacks need their own explicit reporting because nothing else is watching them.