Skip to content

Conversion · Next.js (App Router)

Why I need error tracking before launch in Next.js (App Router)

Analytics tells you a page was visited; it does not tell you the signup button threw on Safari and the visitor left. Client errors are invisible from your side unless something captures them — and a launch is when you have the most traffic and the least idea which browsers it arrives on.

The fix for Next.js (App Router)

13x detects your framework from the response and hands you this version rather than the generic one — below 50% confidence it hedges and gives you the generic one instead.

Sentry's wizard wires the App Router correctly in one command — client, server and edge runtimes each need their own init, and it generates all three:

bash code
npx @sentry/wizard@latest -i nextjs

It creates instrumentation-client.ts, sentry.server.config.ts and sentry.edge.config.ts, and adds the build plugin that uploads source maps — without those, every stack trace you receive points into minified bundle code.

Then add the App Router error hooks, which the wizard does not always create:

ts code
// app/global-error.tsx
"use client";

import * as Sentry from "@sentry/nextjs";
import { useEffect } from "react";

export default function GlobalError({ error }: { error: Error }) {
  useEffect(() => {
    Sentry.captureException(error);
  }, [error]);

  return (
    <html>
      <body>Something went wrong.</body>
    </html>
  );
}

global-error.tsx is the only thing that catches a failure in the root layout, which is exactly the failure that takes the whole site down.

On a different stack? The general version of this fix explains what 13x checks and why it matters, without assuming a framework.

Check your Next.js (App Router) site

113 deterministic checks against your live URL, in about 30 seconds. Framework detected from the response, so every fix comes back in the form your stack actually uses.

No signup. Results in 30 seconds.