Error Tracking with Sentry for AI-Built Applications

Your app is live. Users are hitting it. And somewhere in the background, errors are happening that you know nothing about. Someone tapped a button and got a blank screen. A form submission silently failed. A background job crashed and no one noticed. You found out through a support ticket three days later.

This is the default state of most AI-built apps, and it is entirely fixable. Sentry is the tool that closes the gap between "shipped" and "monitored." It catches errors the moment they happen, tells you exactly what went wrong, who was affected, and what the stack looked like at the time of failure. Think of it as the difference between reconstructing a crime scene from a single eyewitness account and having the whole thing on camera.

The setup takes about twenty minutes. What you learn from it will save you hours.

Why AI-Built Apps Need Error Tracking More Than Most

Here is a stat that should make you pause: 45% of AI-generated code introduces security flaws, according to Veracode's 2025 research. And Veracode was measuring security specifically. The number for general errors and edge case failures is almost certainly higher.

That tracks with how AI coding actually works. AI tools are exceptional at generating the happy path. Give Claude or Copilot a feature spec and it will write code that works perfectly in ideal conditions. But ideal conditions are not what your users bring. They submit forms in unexpected orders, use old browsers, have slow connections that time out, paste emojis into fields that expect ASCII, and do things you never imagined during development. AI does not imagine them either.

The result is a category of bugs that only surface in production, under real usage conditions, with real users. No amount of manual testing during development will catch all of them. You need a system that watches for them in the wild.

How to Use Sentry for Error Tracking

Setting up Sentry is straightforward. The core flow: create an account, create a project, install the SDK, add the DSN, deploy. Here is how it works for a Next.js app.

Go to sentry.io, create a free account, and select Next.js as your platform. Run the official wizard, which handles most of the configuration automatically:

npx @sentry/wizard@latest -i nextjs

The wizard creates three config files for client, server, and edge runtimes. Each initializes Sentry with your DSN:

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

Sentry.init({
  dsn: "https://your-key@o12345.ingest.sentry.io/67890",
  tracesSampleRate: 1.0,
});

Move the DSN to an environment variable (NEXT_PUBLIC_SENTRY_DSN) if your repo is public. Once deployed, confirm the integration by triggering a test error with Sentry.captureException(new Error("test")). If it shows up in your dashboard within thirty seconds, you are live.

What is a Sentry DSN

DSN stands for Data Source Name. It is the address Sentry uses to route error reports from your application to your specific project on their servers. Every project you create in Sentry gets a unique DSN, and every error your app catches gets sent to that address.

The DSN looks like a URL because it functions like one:

https://public-key@o12345.ingest.sentry.io/project-id

The public-key portion identifies your project. The o12345 portion identifies your organization. The project-id at the end routes errors to the correct project within that organization.

Think of the DSN as the address on a crime report form. Every report your app files automatically gets the correct precinct stamped on it before it goes out. Without the DSN, your error reports have nowhere to go.

One important clarification: the DSN is safe to expose in frontend code. It is a write-only key. Anyone who has it can send errors to your project, but they cannot read your error data or access your account. The risk of someone spamming your error quota is real but minor. The only sensitive credential is your auth token, which you use to query the Sentry API and should never be exposed publicly.

Reading Your First Sentry Error Report

When an error lands in Sentry, the default view shows you an issue list. Each row represents a unique error type grouped by Sentry's fingerprinting algorithm. Click any row and you get the full crime scene.

The issue detail page has several sections, and knowing what each one tells you is the difference between solving the bug in five minutes and spending an hour chasing the wrong lead.

The event title is the error message. This is the top line of the stack trace rendered in plain text. For a TypeError, it might read "Cannot read properties of undefined (reading 'user')." For a network error, it might read "Request failed with status code 401." The title tells you the symptom.

The stack trace tells you the location. Sentry renders this as an interactive tree. Click any frame to expand it and see the source code at that line. Without source maps (more on those below), you will see minified code, which is hard to read. With source maps, you see your actual source files with line numbers that match your development environment.

The breadcrumbs are the detective's best tool. They show everything that happened before the error: page navigations, clicks, console logs, network requests, and prior errors. You can often reconstruct the exact user journey that led to the crash just from the breadcrumb trail. A crash that seemed random often becomes obvious when you see that the user navigated directly to a page that requires auth without logging in first.

The tags and context show environment information: which browser, which OS, which version of your app was running, and which user was affected (if you have configured user identification). This is where you find out that your bug only happens in Safari on iOS 16, or only for users in a specific geographic region, or only in the version you deployed on Tuesday.

The "seen by" count tells you how widespread the problem is. An error that has happened once in 10,000 sessions is different from one that happens on every third page load. Sentry shows you both the raw count and the percentage of sessions affected, so you can triage by impact rather than just chronology.

Can Sentry Track Errors in Real-Time

Yes, and this is one of its most underappreciated features for indie builders. Sentry processes and surfaces errors within seconds of them occurring. When a user hits a crash, you can have the full report in your dashboard before they finish composing a support message.

The practical implication is that you can watch your dashboard during a launch or a major feature release and catch regressions as they happen, not hours later. Sentry also supports alerts that notify you via email, Slack, or PagerDuty when an error occurs for the first time, when an error's frequency crosses a threshold, or when a previously resolved error reappears.

Setting up a basic alert takes two minutes. In your Sentry project, go to Alerts and create a new issue alert. The most useful starting rule is: notify me when a new issue is created. That way, the first time any new error type occurs, you find out immediately. You can add a second rule for high-volume errors: notify me when an issue occurs more than 10 times in 1 hour. That combination covers both new failures and widespread ones.

For AI-built apps specifically, real-time tracking is especially valuable in the first 48 hours after a deployment. AI-generated code often handles common flows well but has brittle error handling around edge cases. Real usage will surface these within hours of launch. Being notified immediately means you can push a fix before the error accumulates thousands of occurrences and before users lose trust.

Source Maps Make Stack Traces Readable

One gap that trips up most first-time Sentry users is deploying without source maps. In production, JavaScript gets minified and bundled. Variable names become single letters, and line numbers refer to positions in a single 50,000-character file. A Sentry stack trace from a minified bundle looks like:

TypeError: Cannot read properties of undefined (reading 'u')
    at e (https://your-app.com/_next/static/chunks/main.js:1:47823)
    at t (https://your-app.com/_next/static/chunks/main.js:1:48012)

That tells you almost nothing. With source maps uploaded to Sentry, the same error reads:

TypeError: Cannot read properties of undefined (reading 'user')
    at handleSubmit (src/components/LoginForm.tsx:34:12)
    at FormProvider (src/context/FormContext.tsx:89:5)

Now it tells you exactly where to look. The Sentry Next.js wizard automatically configures source map uploading via the Sentry webpack plugin. You need to add your Sentry auth token to your environment variables as SENTRY_AUTH_TOKEN, and source maps will be uploaded on every build. Without this step, your Sentry reports are technically complete but practically difficult to act on.

The most common source map failure mode is forgetting to set the auth token. The build completes without errors, the deploy succeeds, and you assume source maps are working until you hit your first production crash and see minified output.

Managing Noise and Triaging Issues

Sentry groups errors by fingerprint, a hash computed from the error message and stack trace. Two instances of the same error in the same function get grouped into one issue. This prevents your dashboard from filling with duplicates, but it requires some tuning out of the box.

The most common noise source for vibe coders is network errors from third-party services. If an external API returns 500 errors across an hour, you get hundreds of occurrences of the same issue. Set up inbound data filters in Project Settings to suppress errors from domains you cannot control. Also enable "Filter out known browser extension errors" to prevent injected extension code from polluting your issue list.

Once the noise floor is low, triage becomes simple. Open your issues list after every deployment. Sort by "First Seen" to catch new regressions. Sort by "Users Affected" to prioritize by impact. For each issue, decide: fix now, fix later, or ignore. When you mark an issue resolved and it reappears after your next deploy, Sentry reopens it automatically and notifies you. That regression detection alone is worth the setup time.

What Sentry Will Teach You About AI-Generated Code

After a few weeks of watching Sentry on an AI-built app, a pattern emerges. The errors cluster around predictable failure modes.

Undefined access errors are the most common. AI-generated code assumes data will always be present. user.profile.avatar.url works in testing when every profile is complete. It crashes in production when a user signed up via OAuth and never filled in their profile.

Missing error handling around async operations is the second pattern. AI writes the happy path well. It often skips the fallback for when the API call times out or returns empty instead of populated. Real users hit those fallbacks constantly.

None of these are failures of the AI tool. They are the predictable shape of code generated without observing real user behavior. Sentry is how you observe that behavior and feed it back into your process. Each error you catch and fix makes your app more robust than it was when it left the AI's hands.