Prompt of the Day: Add Sentry Error Tracking to Your Next.js App

Series: Prompt of the Day — Part 3 of 30 | Track: Prompts | By Tom Hundley

---

The 2 AM Wake-Up Call You Can Avoid

It was a Tuesday night. A solo founder—let's call him Marcus—had just shipped his SaaS MVP after six weeks of vibe coding with Cursor. He went to bed proud. By 2 AM his phone was buzzing. A handful of beta users couldn't complete checkout. By morning, he'd lost seven signups.

The worst part? The error had been there since launch. Marcus had no monitoring in place. He found out about the bug the same way his users did: by running into it.

This is the predictable failure mode of shipping without error tracking. And it's completely avoidable with one terminal command and one good prompt.

Here's the thing about vibe coding: according to a 2025 analysis by Add Jam, "when you don't fully understand every line of code, good monitoring becomes essential." That's not a criticism—it's just the reality of AI-assisted development. You're shipping faster than you can mentally model every code path. Sentry fills that gap.

---

The Prompt

Add Sentry error tracking to this Next.js 14+ App Router project. Use the official @sentry/nextjs SDK.

Please:
1. Run the Sentry wizard: npx @sentry/wizard@latest -i nextjs
2. After wizard setup, show me the three config files it creates:
   - instrumentation-client.ts (browser)
   - sentry.server.config.ts (Node.js)
   - sentry.edge.config.ts (Edge runtime)
3. Wrap next.config.ts with withSentryConfig, enabling:
   - Source map uploads for readable production stack traces
   - Tunneling to bypass ad blockers (tunnelRoute: "/monitoring")
   - Silent mode except in CI
4. Add a /app/sentry-test/page.tsx route with a button that throws a test error, so I can verify the integration works
5. Show me how to set NEXT_PUBLIC_SENTRY_DSN and SENTRY_AUTH_TOKEN in .env.local and remind me which one is safe to commit
6. Add a try/catch example inside a Server Action using Sentry.withServerActionInstrumentation

My Sentry org slug is [YOUR_ORG] and project slug is [YOUR_PROJECT].

---

Why It Works

This prompt works because it's specific about the runtime split. Next.js doesn't run in one environment—it runs in three: the browser, Node.js on the server, and the Edge runtime for middleware and edge functions. A vague prompt like "add Sentry" often results in only the client being instrumented. You'll catch frontend errors but miss every server-side crash and API route failure.

By naming all three config files explicitly, you force the AI to handle all three runtimes correctly.

The tunnelRoute instruction matters in practice. Without it, Sentry's reporting endpoint gets blocked by a meaningful portion of users running ad blockers—you lose visibility into exactly the kind of power users who tend to be early adopters.

Source map uploads are the difference between seeing:

Error at a.b.c (main-abc123.js:1:49823)

...and seeing:

Error at processCheckout (app/checkout/actions.ts:47)

One you can debug in minutes. The other sends you down a two-hour rabbit hole.

Finally, asking for the Server Action instrumentation example matters because Sentry's docs for Next.js show Sentry.withServerActionInstrumentation as a first-class pattern for App Router—but most AI responses omit it unless you ask directly.

What the output looks like

After a good wizard run, your project gets these files automatically:

// instrumentation-client.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 1.0,
  replaysOnErrorSampleRate: 1.0,
  replaysSessionSampleRate: 0.1,
  integrations: [
    Sentry.replayIntegration(),
  ],
});

// sentry.server.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 1.0,
  // Disable console.log capture in dev to reduce noise
  _experiments: { enableLogs: true },
});

// next.config.ts (after withSentryConfig wrap)
import { withSentryConfig } from "@sentry/nextjs";

export default withSentryConfig(nextConfig, {
  org: "your-org-slug",
  project: "your-project-slug",
  silent: !process.env.CI,
  widenClientFileUpload: true,
  tunnelRoute: "/monitoring",
  disableLogger: true,
});

And the Server Action pattern:

// app/actions/checkout.ts
import * as Sentry from "@sentry/nextjs";
import { headers } from "next/headers";

export async function processCheckout(formData: FormData) {
  return Sentry.withServerActionInstrumentation(
    "processCheckout",
    {
      headers: await headers(),
      formData,
      recordResponse: true,
    },
    async () => {
      // your checkout logic here
      const result = await chargeCard(formData);
      return { success: true, data: result };
    }
  );
}

This wires up distributed tracing—so when a user's browser session triggers a server action that fails, you see the entire chain in one Sentry trace, not two disconnected events.

---

The Anti-Prompt

Don't write this:

Add error tracking to my Next.js app

Why it fails:

This prompt is so underspecified that the AI will make three harmful assumptions:

1. It might install the wrong package. Older tutorials use @sentry/react or @sentry/node separately. For Next.js you need @sentry/nextjs—a unified SDK that handles all three runtimes.

2. It will probably skip server instrumentation. Without explicit instruction, the AI defaults to client-side setup. Your API routes, Server Actions, and middleware go unmonitored.

3. It won't configure source maps. So when something breaks in production, your stack traces are minified gibberish. The Stack Overflow 2025 Developer Survey found that 45% of developers say "debugging AI-generated code is more time-consuming"—minified traces with no source maps are a huge contributor to that problem.

You'll think you have error tracking. You'll have a partial setup that gives you false confidence.

---

Variations

For teams already using Sentry (adding to existing project):

I have an existing Sentry account with org "acme" and project "acme-web".
My Next.js app already has a sentry.client.config.ts from an old Pages Router setup.
Migrate it to the new App Router instrumentation pattern using instrumentation-client.ts
and instrumentation.ts. Keep my existing DSN and alert rules. Show me a diff.

For adding Session Replay (great for debugging UX issues):

In my existing Sentry Next.js setup, enable Session Replay with these settings:
- Capture 10% of all sessions
- Capture 100% of sessions where an error occurs
- Mask all input fields containing "password", "card", "cvv", or "ssn"
Show the updated instrumentation-client.ts.

For Slack alerts on new errors:

I have Sentry connected to our Slack workspace.
Create a Sentry alert rule that fires a Slack message to #eng-alerts when:
- A new issue appears for the first time
- An existing issue regresses after being marked resolved
- Any issue affects more than 50 unique users in 1 hour
Format the Slack message to include: issue title, affected URL, user count, and a direct link to Sentry.

---

Why This Matters Right Now

Sentry's AI debugger Seer—now generally available as of June 2025—has analyzed over 38,000 issues and identifies root causes with 94.5% accuracy. It's also saved developers over two years of collective debugging time since beta.

But Seer only works if Sentry is actually capturing your errors with full context: traces, source maps, user data, server action metadata. A partial Sentry setup gives Seer partial information, which means partial fixes.

The prompt above gives you the full setup. That's the prerequisite for everything else.

As one analysis of Sentry's evolution put it, AI is enabling teams to ship more, more frequently—which means error volume is exploding. The teams winning in production are the ones with the observability foundation in place before things go wrong.

---

Your Checklist

• ☐ Run npx @sentry/wizard@latest -i nextjs and complete the wizard
• ☐ Confirm three config files were created: instrumentation-client.ts, sentry.server.config.ts, sentry.edge.config.ts
• ☐ Verify next.config.ts is wrapped with withSentryConfig and tunnelRoute is set
• ☐ Add NEXT_PUBLIC_SENTRY_DSN to .env.local (safe to commit) and SENTRY_AUTH_TOKEN to .env.local (do NOT commit — add to .gitignore)
• ☐ Visit your /sentry-test route, click the error button, and confirm the error appears in your Sentry dashboard within 30 seconds
• ☐ Wrap at least one Server Action with Sentry.withServerActionInstrumentation
• ☐ Set tracesSampleRate to 0.2 (20%) in production to control costs—1.0 is fine for dev/staging
• ☐ Add a Slack or email alert for new issues so you find out before your users do

---

Ask The Guild

Community prompt for this week:

What's the most surprising error Sentry caught in your production app that you never would have found through testing? Drop your story in the comments—especially if it was something an AI assistant wrote that looked totally fine in code review.

Bonus points if you share the Sentry config trick that made it catchable.