What Is Sentry? Error Tracking That Tells You What Broke Before Your Users Do

Why Every Vibe Coder Needs This

Here is the uncomfortable truth about shipping apps built with AI: the code works great in your local environment. You test it, it looks fine, you deploy it. Then real users arrive with different browsers, weird screen sizes, unexpected inputs, and slow internet connections — and things break in ways you never anticipated.

Without a tool like Sentry, here is what your error-discovery process looks like: a user either screenshots the broken screen and sends it to you, or they silently leave and never come back. You find out days later, or never. By the time you know there is a problem, dozens of people have already hit the same wall.

With Sentry, the moment that error happens, you get an email (or Slack message, or whatever you prefer) that says: "Hey, this specific function in this specific file just threw this exact error for this specific user, on this browser, at this timestamp." You wake up to a bug report that already contains the diagnosis.

Think of it like the difference between owning a rental property with and without a property management company. Without one, you find out about a burst pipe when the tenant has already been dealing with water damage for a week. With one, you get a call the minute the leak starts. Sentry is your property manager for production code.

This matters especially for vibe coders because AI-generated code tends to be optimistic. The AI writes code that handles the happy path beautifully but often misses the edge cases that real users reliably stumble into. Sentry is what catches those edge cases when they inevitably appear.

Real Scenario: Your App Breaks at 2am

You built a contact form for a client's site. The AI generated the whole thing — the form, the email-sending logic, the success message. You tested it on your laptop, it worked perfectly. You deployed it on Friday afternoon and went home.

At 2:17am Saturday, a user in Germany with an email address containing a special character submits the form. Your email-sending function crashes. They see a blank page. They leave. Without Sentry, you find out Monday when the client asks why their inbox has been quiet all weekend.

With Sentry, at 2:17am you get this in your email:

You wake up Monday, open the Sentry dashboard, see the exact line, copy the error into Claude, and have a fix deployed before the client even brings it up. That is the power of Sentry in practice.

What the AI Generates When You Add Sentry

When you ask an AI coding assistant to add Sentry to your project, here is a typical prompt and what comes back. Understanding each piece means you can configure it correctly and know when something is wrong.

Add Sentry error tracking to my Next.js app. I want to:
- Catch all unhandled errors automatically
- See which user was affected when an error happens
- Get emailed when something breaks in production
- Track both frontend errors and API route errors
Tell me what to install and show me the full setup code.

The AI will typically generate something like this:

# Install the Sentry SDK for Next.js
npm install @sentry/nextjs

# Run Sentry's setup wizard
npx @sentry/wizard@latest -i nextjs

After the wizard runs, it creates several files. Here is what the most important one looks like, and what each part actually does:

// sentry.client.config.ts
// This file runs in the browser (your users' devices)

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

Sentry.init({
  dsn: "https://abc123@o456789.ingest.sentry.io/987654",

  // What percentage of errors to capture (1.0 = 100%)
  tracesSampleRate: 1,

  // What percentage of sessions to record (for replay)
  replaysSessionSampleRate: 0.1,

  // Always record sessions that had an error
  replaysOnErrorSampleRate: 1.0,

  // Show Sentry's debug panel in development
  debug: false,
});

And the server-side configuration:

// sentry.server.config.ts
// This file runs on your server (API routes, server components)

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

Sentry.init({
  dsn: "https://abc123@o456789.ingest.sentry.io/987654",

  tracesSampleRate: 1,

  debug: false,
});

Understanding Each Part of the Sentry Setup

AI will generate this code, but it helps to know what each piece is actually doing — so you can change settings confidently instead of being afraid to touch anything.

The DSN: Your App's Unique Address

That long URL starting with https://abc123@o456789.ingest.sentry.io/ is called a DSN (Data Source Name). Think of it as your app's mailing address at Sentry. When an error happens, the SDK uses this address to know exactly which Sentry project to send the error report to. Every project you create in Sentry gets its own DSN.

Important: your DSN is meant to be in client-side code (it is designed to be public), but you should still store it in an environment variable rather than hardcoding it. The AI should generate it as process.env.NEXT_PUBLIC_SENTRY_DSN. If it hardcodes the value directly, ask it to use an environment variable instead.

tracesSampleRate: How Much Data to Collect

The tracesSampleRate: 1 setting means "capture 100% of errors and performance traces." For a small app or side project, keep this at 1 — you want to see everything. For a high-traffic app getting millions of requests, you might lower this to 0.1 (10%) to avoid hitting Sentry's event limits. The AI will almost always set this to 1, which is right for beginners.

replaysSessionSampleRate: Session Recordings

Sentry has a feature called Session Replay — it records a video-like playback of what the user was doing when an error happened. Like a security camera for your app. The replaysSessionSampleRate: 0.1 means "record 10% of all sessions." The replaysOnErrorSampleRate: 1.0 means "always record a session that had an error" — so every crash comes with a full replay. This is extremely useful for understanding what the user was actually doing.

The Error Boundary for React Components

For React apps, the AI will often also generate an error boundary component. This catches errors that happen inside React's component tree — crashes that occur while rendering your UI — and sends them to Sentry instead of just showing a blank white screen.

// app/global-error.tsx
// Catches errors in the entire app

"use client";

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

export default function GlobalError({
  error,
}: {
  error: Error & { digest?: string };
}) {
  useEffect(() => {
    // Send the error to Sentry when it happens
    Sentry.captureException(error);
  }, [error]);

  return (
    
      
        {/* Show a friendly error page instead of a blank screen */}
        
      
    
  );
}

Identifying Users in Error Reports

Out of the box, Sentry tells you that an error happened, but not necessarily who it happened to. To link errors to specific users, you add a small piece of code wherever you know who the user is (usually after login):

// After a user logs in, tell Sentry who they are
import * as Sentry from "@sentry/nextjs";

// Call this when a user authenticates
function onUserLogin(user: { id: string; email: string; name: string }) {
  Sentry.setUser({
    id: user.id,
    email: user.email,
    username: user.name,
  });
}

// Call this when a user logs out
function onUserLogout() {
  Sentry.setUser(null);
}

Once you add this, every Sentry error report will show exactly which user account was affected — letting you proactively reach out to impacted users or reproduce their specific scenario.

What You See in the Sentry Dashboard

When you open Sentry after an error has been captured, here is what you are actually looking at and what each section means.

Issues: Your Error Inbox

The Issues tab is the main view — a list of every distinct error your app has thrown. Sentry groups errors intelligently, so if 500 users all hit the same bug, you see one entry that says "500 occurrences" rather than 500 separate reports. This grouping is called "issue deduplication" and it is one of Sentry's most valuable features. Instead of drowning in individual alerts, you see which errors are genuinely widespread versus which ones happened once.

Each issue shows you:

• The error message — exactly what went wrong in plain text
• The file and line number — where in your code it happened
• First seen / Last seen — when this error started happening
• Frequency — how often it is occurring (is it getting worse?)
• Users affected — how many unique users have hit this bug

The Stack Trace: Your Breadcrumb Trail

Click into any issue and you see a stack trace. This is the most useful thing Sentry provides and it looks intimidating at first, but it is actually just a list of steps the code took before crashing. Think of it like a receipt from a restaurant showing every dish that was ordered before the kitchen caught fire on the last one.

The stack trace shows you:

1. The exact line where the crash happened (highlighted at the top)
2. Every function call that led to that line, going backward through your code
3. The actual values of variables at the moment of the crash

You do not need to understand all of this yourself. The best use of a Sentry stack trace is to copy the entire thing and paste it into your AI coding assistant with the prompt: "This error happened in my app. Here is the full stack trace. What caused it and how do I fix it?"

Breadcrumbs: What the User Did Before the Crash

Sentry also automatically records a timeline of what happened in the app before the error — page navigations, button clicks, API calls, console messages. This timeline is called "breadcrumbs." It is like having footage from the moments leading up to an incident. Often the crash itself is a symptom; the breadcrumbs show you the actual cause.

Session Replay: Watch What Happened

If you have enabled Session Replay, clicking the "Replay" tab shows you an actual recording of the user's screen — like a screen recording, but reconstructed from DOM events rather than video. You can watch exactly what the user clicked, what they typed, and what they saw before and during the error. This is invaluable for bugs that are hard to reproduce.

What AI Gets Wrong About Sentry

AI coding assistants are good at generating the initial Sentry setup, but there are several mistakes they make consistently. Know these in advance and you will save hours of confusion.

Hardcoding the DSN instead of using environment variables

The most common mistake. AI will sometimes paste your actual DSN directly into the config files instead of referencing an environment variable:

// ❌ What AI sometimes generates
Sentry.init({
  dsn: "https://abc123@o456789.ingest.sentry.io/987654",
  // This value is hardcoded — it will be visible in your Git history
});

// ✅ What you actually want
Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  // Value comes from your .env file, not the code itself
});

While your DSN being public is not a catastrophic security issue (it only allows sending errors to your Sentry project), it is sloppy practice and can lead to hitting your error quota from unauthorized sources. Always use an environment variable. Add NEXT_PUBLIC_SENTRY_DSN=your_dsn_here to your .env.local file.

Setting tracesSampleRate to 1 in production without warning

For side projects and low-traffic apps, capturing 100% of traces is fine. But if your app grows and you are processing thousands of requests per minute, tracesSampleRate: 1 will blow through Sentry's free tier instantly. AI does not always flag this. A good production setting for a growing app is 0.1 (10%) for performance traces, while keeping error capture at 100%. Ask your AI to set different sample rates for development and production:

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  // In production, sample 10% of traces (still captures all errors)
  tracesSampleRate: process.env.NODE_ENV === "production" ? 0.1 : 1.0,
});

Forgetting to add Sentry to API routes and server components

In a Next.js app, errors can happen in three places: the browser (client components), the server (server components and API routes), and the edge runtime. AI often sets up client-side Sentry correctly but misses server-side configuration. If your API route crashes, client-side Sentry will not catch it — you need sentry.server.config.ts set up as well. Always verify you have separate config files for client and server.

Not wrapping async operations in try/catch

Sentry automatically catches synchronous errors and unhandled promise rejections. But if your code has asynchronous operations inside a try/catch block that swallows errors silently (catches the error and does nothing with it), Sentry will never see those errors. AI sometimes generates overly defensive code that catches everything without reporting it:

// ❌ Error is caught but never reported to Sentry
async function fetchUserData(userId: string) {
  try {
    const data = await db.user.findUnique({ where: { id: userId } });
    return data;
  } catch (error) {
    console.log("Something went wrong"); // Error disappears here
    return null;
  }
}

// ✅ Error is caught, reported to Sentry, then handled
async function fetchUserData(userId: string) {
  try {
    const data = await db.user.findUnique({ where: { id: userId } });
    return data;
  } catch (error) {
    Sentry.captureException(error); // Tell Sentry about it
    return null; // Still handle gracefully for the user
  }
}

Using Sentry in a way that leaks user PII

Sentry captures a lot of context automatically — request headers, URL parameters, user data you have set via Sentry.setUser(). AI does not always remind you to scrub sensitive data. If a user submits a form with their password and your API route crashes, Sentry might capture the full request body including that password. Use Sentry's beforeSend hook to strip sensitive fields before they leave your server:

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  beforeSend(event) {
    // Remove sensitive fields from request data before sending to Sentry
    if (event.request?.data) {
      delete event.request.data.password;
      delete event.request.data.creditCard;
      delete event.request.data.ssn;
    }
    return event;
  },
});

How to Debug with AI Using Sentry

The real superpower of Sentry for vibe coders is not just knowing that something broke — it is having everything you need to fix it in one place, ready to hand to your AI coding assistant. Here is the workflow that turns a production error into a deployed fix in under an hour.

Step 1: Get the full error context from Sentry

When Sentry alerts you to an error, click through to the issue page and collect:

• The error message and type (at the top of the issue)
• The full stack trace (copy all of it, not just the top line)
• The breadcrumbs (what happened before the crash)
• The request data (what URL was called, what data was sent)
• The user context (browser, OS, user ID if you have set it up)

Step 2: Give AI the full context in one prompt

Do not just paste the error message. Give the AI everything:

My Next.js app has a production error captured by Sentry.
Here is the full context:

ERROR:
TypeError: Cannot read properties of undefined (reading 'split')

STACK TRACE:
  at formatEmail (app/api/contact/route.ts:34:22)
  at POST (app/api/contact/route.ts:18:14)
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

BREADCRUMBS (what happened before the error):
1. User navigated to /contact
2. User filled in email field with: user@müller-design.de
3. User clicked submit
4. POST /api/contact was called with body:
   {"email":"user@müller-design.de","message":"Hello there"}

Here is the code in app/api/contact/route.ts:
[paste your code here]

What caused this error and how do I fix it?

Step 3: Reproduce it locally before deploying the fix

Once AI suggests a fix, do not deploy it blindly. Try to reproduce the original error locally first using the same data that caused the crash (Sentry gives you the exact request payload). Apply the fix, verify the error is gone locally, then deploy. After deploying, monitor the Sentry issue — if it was fixed correctly, you will see "Resolved" status and no new occurrences.

Step 4: Mark the issue as resolved in Sentry

After you deploy your fix, open the Sentry issue and click "Resolve." Sentry will automatically "unresolve" it and re-alert you if the same error happens again after your fix — so you know if your fix worked or if there is a related edge case you missed.

Step 5: Add a test to prevent regression

Once you have fixed a real production bug, ask your AI to write a test that would have caught it:

We just fixed a bug where the contact form crashed when the
email address contained special characters like ü, ö, ä, or ñ.
Here is the fixed function:
[paste fixed code]

Write a test that verifies this function handles:
1. A standard email address
2. An email with unicode characters like user@müller-design.de
3. An email with a plus sign like user+tag@example.com
4. An empty string

Sentry vs Logging vs Just Checking Vercel Logs

If you have been building for a while, you might be wondering: "Can't I just look at my Vercel logs? Or add more console.log statements?" The answer is: those tools have their place, but they are not substitutes for error tracking. Here is how they compare.

The mental model is: logging is like a detailed journal — great for understanding what happened if you go looking. Monitoring is like a health dashboard — tells you the overall state of your system. Sentry is like an alarm system — it activates when something specific goes wrong and tells you exactly what that thing was.

You want all three eventually. But if you are just starting out and have to pick one tool to add first, Sentry gives you the most immediate value per minute of setup time.

Setting Up Alerts So Sentry Actually Wakes You Up

Sentry's dashboard is only useful if you look at it. The more important feature is alerts — getting notified automatically when something breaks. Here is how to set this up so you are always in the loop.

Email alerts (default)

Out of the box, Sentry emails you when a new issue is detected or when a resolved issue comes back. You can configure this in your project settings under Alerts. For most vibe coders, the default email setup is enough to start.

Slack integration

If you are already in Slack for other things, connecting Sentry to a Slack channel means your errors show up where you are already looking. In your Sentry project settings, go to Integrations, find Slack, and follow the setup. You can create alert rules like "notify #errors channel whenever a new issue is detected" or "alert me if the same issue occurs more than 10 times in one hour."

Alert rules for severity

Not every error deserves to wake you up at 2am. Use alert rules to separate the noise from the signal:

• Critical alerts (immediate): Any new issue in your checkout or payment flow
• High alerts (hourly digest): Any issue that affects more than 5 unique users
• Low noise (daily digest): Single-occurrence errors that have not recurred

Ask your AI to help you write Sentry alert rules for your specific app if you are unsure where to start.

Getting Sentry Running in 10 Minutes

Here is the fastest path from zero to Sentry capturing real errors in your app.

Step 1: Create a free Sentry account

Go to sentry.io, create an account, and create a new project. Choose your framework (Next.js, React, Node.js, etc.). Sentry will give you your DSN and walk you through setup.

Step 2: Run the setup wizard (for Next.js)

# In your project directory
npx @sentry/wizard@latest -i nextjs

# The wizard will:
# 1. Install the @sentry/nextjs package
# 2. Create sentry.client.config.ts and sentry.server.config.ts
# 3. Update your next.config.js
# 4. Create an example error page for testing

Step 3: Add your DSN to your environment variables

# In your .env.local file
NEXT_PUBLIC_SENTRY_DSN=https://your-dsn@sentry.io/your-project-id
SENTRY_ORG=your-org-slug
SENTRY_PROJECT=your-project-slug
SENTRY_AUTH_TOKEN=your-auth-token

Step 4: Test that errors are being captured

Sentry's wizard creates a test page at /sentry-example-page that you can visit to intentionally trigger an error and verify it shows up in your Sentry dashboard. Always test this before relying on Sentry in production.

# Trigger a test error
# Visit: http://localhost:3000/sentry-example-page
# Click the "Throw Error" button
# Then check your Sentry dashboard — the error should appear within seconds

Step 5: Add user identification after login

// In your auth handler (after user logs in)
import * as Sentry from "@sentry/nextjs";

// Example using NextAuth
export async function afterLogin(session: Session) {
  if (session.user) {
    Sentry.setUser({
      id: session.user.id,
      email: session.user.email ?? undefined,
    });
  }
}

What to Learn Next

Sentry handles the "something broke, here is what" layer. To complete your production-readiness picture, here is where to go next:

• What Is PostHog? — Sentry tells you when things break. PostHog tells you how users are actually using your app — what features they click, where they drop off, and what paths they take. Together, these two tools give you the full picture of what users experience.
• What Is Logging? — Structured logs complement Sentry perfectly. Logs give you a detailed journal of everything your app did. When Sentry shows you an error, logs tell you the full story of what led up to it.
• What Is Monitoring? — Monitoring is the broader category that Sentry fits into — tracking the health and performance of your system over time. Understanding monitoring helps you know which tools to use for which layer of observability.
• How to Debug AI-Generated Code — A systematic approach to fixing code that AI wrote but that is failing in production. Pairs perfectly with Sentry: Sentry finds the bug, this guide helps you fix it effectively using AI.

Frequently Asked Questions

Is Sentry free to use?

Yes, Sentry has a free tier that covers 5,000 errors per month — more than enough for a new app or side project. Paid plans start when you need higher volume, more team seats, or features like data retention beyond 90 days. Most vibe coders stick with the free tier for months before needing to upgrade.

Does Sentry slow down my app?

In practice, no. The Sentry SDK runs in the background, collecting error data asynchronously. It does not block your app from loading or responding. The impact is typically measured in single-digit milliseconds. Sentry also has a sample rate setting so you can tell it to only track a percentage of traces if you are worried about performance on very high-traffic apps.

What is the difference between Sentry and console.log?

console.log only shows output in the terminal or browser console when someone is actively watching. If an error happens at 2am while you are asleep, console.log shows nothing useful — the output disappears when the process ends or the browser tab closes. Sentry captures errors automatically, stores them permanently, sends you an alert, and shows you the full context regardless of when it happened.

Can I use Sentry with AI-generated code?

Yes — and this is exactly where Sentry shines. AI-generated code often works in testing but breaks on unexpected inputs in production. Sentry catches those breaks automatically and gives you the exact error message, stack trace, and user context. You can paste that directly into your AI coding assistant and ask it to fix the bug, turning a mystery into a solved problem in minutes.

What is a stack trace and why does Sentry show me one?

A stack trace is like a breadcrumb trail showing exactly which lines of code ran before the error happened. Think of it as a receipt — it shows every function that was called, in order, until something crashed. Sentry shows you this trail so you know exactly where in your code the bug lives, instead of having to guess. You can copy a Sentry stack trace directly into your AI assistant and ask it to explain the bug.