Sentry in Next.js: the useful minimum for catching errors

Short answer: run npx @sentry/wizard@latest -i nextjs, set SENTRY_DSN and initialise the SDK in instrumentation.ts; for rendering errors add app/global-error.tsx. From there every exception arrives with a stack trace and a route.

The wizard and what it writes

npx @sentry/wizard@latest -i nextjs
npx next build

The wizard creates instrumentation.ts and instrumentation-client.ts, wraps next.config.ts with withSentryConfig and writes the DSN into .env.local. Read the diff before you commit: the default setup includes source map upload.

Server: instrumentation.ts

import * as Sentry from "@sentry/nextjs";

export async function register() {
  Sentry.init({
    dsn: process.env.SENTRY_DSN,
    environment: process.env.NODE_ENV,
    tracesSampleRate: 0.1,
  });
}

export const onRequestError = Sentry.captureRequestError;

onRequestError is the hook Next.js calls on route errors: without it, server-side errors stay in the logs and never become events. tracesSampleRate: 0.1 keeps 10% of transactions, not of errors.

Client: global-error.tsx

"use client";

import * as Sentry from "@sentry/nextjs";

export default function GlobalError({ error }: { error: Error }) {
  Sentry.captureException(error);
  return (
    
      
        Something went wrong.
      
    
  );
}

This file catches rendering errors that escape the segment error boundaries and replaces the whole page. captureException belongs before the return: a failure during render gets no second chance.

What to filter before it is too late

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  ignoreErrors: [/ResizeObserver loop/, /^NetworkError$/],
  beforeSend(event) {
    if (event.request?.headers) delete event.request.headers.cookie;
    return event;
  },
});

ResizeObserver and NetworkError are known noise: they fill the quota without pointing at a bug. The filter on headers.cookie stops sessions from reaching the service, and it is an obligation before you send data of real users.

A named limitation

Sentry is an external service: the SDK is MIT, the hosted service is not. Every event leaves your infrastructure, so choosing what to send and how long to keep it stays your responsibility. A self-hosted option exists and costs more to maintain.

Where to continue

In the catalogue start from the shadcn library, the alert toast record and the animated skeleton. For the rest read error boundaries in App Router, the common build errors and the comparison Vercel analytics or self-hosted.