Catch errors in production

Step by step

1. 1

   Pick an error tracker

   Sentry is the default and what most vibe coders should use — it covers frontend, backend, and source maps in one SDK. Alternatives worth knowing: Highlight.io (adds session replay), Rollbar, or Better Stack if you want logs and errors together. Don't try to hand-roll this with console.error and a log file; you'll never see the errors that matter.

2. 2

   Run the official install wizard

   For Next.js, run `npx @sentry/wizard@latest -i nextjs`. It generates the config files, wraps next.config with withSentryConfig, wires up the client, server, and edge runtimes, and drops in your DSN. Frameworks like SvelteKit, Remix, and plain Node have equivalent wizards. Let the tool scaffold it — the manual setup has too many moving parts to get right by hand.

3. 3

   Store the DSN and auth token as env vars

   The public DSN goes in an env var (NEXT_PUBLIC_SENTRY_DSN for client, SENTRY_DSN for server). The SENTRY_AUTH_TOKEN — needed for uploading source maps — must be set in your build environment (e.g. Vercel project settings), never committed. Set separate environments so staging noise doesn't drown out real production errors.

4. 4

   Upload source maps and tag releases

   Without source maps, every production stack trace is unreadable minified garbage like `a.b is not a function` at `chunk-4f2.js:1:9021`. The wizard adds a build-time upload step — confirm it runs in CI/Vercel. Tag each release with your git SHA so an error links straight to the commit that caused it.

5. 5

   Add user and feature context

   A bare exception is hard to triage. Call Sentry.setUser({ id }) after login, and enrich manual captures with tags (feature: 'checkout') and extra data. Then when checkout breaks you can see it's one specific user on one specific route, not a mystery. Scrub secrets first (see pitfalls).

6. 6

   Set sample rates and silence known noise

   Set tracesSampleRate to 0.1 or lower in production — 1.0 will burn through your quota and bill fast. Use ignoreErrors / beforeSend to drop noise you can't fix (browser extension errors, ResizeObserver warnings, aborted fetches) so real signal isn't buried.

7. 7

   Route alerts to where you'll see them

   Connect Sentry to Slack or email, but alert on *new issues*, *regressions*, and *spikes* — not every single event. Getting pinged 400 times an hour trains you to ignore alerts entirely. One message when a new bug appears is what you want.

8. 8

   Verify it actually catches errors

   Throw a deliberate error in a deployed route (`throw new Error('sentry test')`) and confirm it lands in the dashboard within a minute — with a readable, source-mapped stack trace pointing at your real .ts file. If the trace is minified, source maps aren't uploading. Don't trust setup you haven't seen fire.

// instrumentation.ts — Next.js runs this before your app boots
import * as Sentry from "@sentry/nextjs";

export async function register() {
  Sentry.init({
    dsn: process.env.SENTRY_DSN,
    environment: process.env.VERCEL_ENV ?? "development",
    tracesSampleRate: 0.1,   // 10% of requests get perf traces
    sendDefaultPii: true,    // attach user + request context
  });
}

// Next.js hands every uncaught server error to this hook
export const onRequestError = Sentry.captureRequestError;

// Anywhere you catch an error yourself, enrich it before sending:
export async function chargeCard(userId: string, cents: number) {
  try {
    await stripe.paymentIntents.create({ amount: cents /* ... */ });
  } catch (err) {
    Sentry.captureException(err, {
      user: { id: userId },
      tags: { feature: "checkout" },
      extra: { cents },
    });
    throw err; // still let the caller handle/surface it
  }
}