Sentry Setup Checklist for AI-Built Apps

By Ohad Krispin, founder of VibeRaven · LinkedIn

Check what Sentry code the repo already has, then run Sentry's wizard with npx @sentry/wizard@latest -i nextjs for Next.js, or install @sentry/react for a Vite + React app. Put the DSN in your Vercel Production and Preview variables, set an environment and a release on every event, upload source maps from the production build and add one alert rule. Finish on a preview deployment: throw one test error from the browser and one from a server route, and find both in Sentry Issues with readable stack traces.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Why it matters

Why this matters

Reviewed on 15 October 2026 against Sentry's Next.js, React, source map, Vercel integration and alert docs, and Vercel's and Vite's environment variable docs. No Sentry project was used for this page, so the steps are a manual recipe, not an observed customer result. Sentry can be installed and still tell you nothing after launch: with no DSN the SDK sends no events, without source maps a stack trace points at minified bundle files, and without an environment tag preview and production errors land in the same list.

Checklist

Set up Sentry in this order

01Check what is already there before you run a wizard. Look in package.json for @sentry/nextjs or @sentry/react, for the files Sentry's Next.js wizard writes (instrumentation-client.ts, sentry.server.config.ts, sentry.edge.config.ts, instrumentation.ts and a withSentryConfig wrapper in next.config), for an .env.sentry-build-plugin file, and in your Vercel project for SENTRY_ variables. Finish a half-wired setup instead of starting a second one.
02
Next.js: run Sentry's wizard. Sentry's Next.js guide says it creates init files for the browser, the Node.js server and the edge runtime, registers the server ones in instrumentation.ts with onRequestError, wraps next.config in withSentryConfig for source map upload, adds app/global-error.tsx, and adds a /sentry-example-page with a test API route.
```
npx @sentry/wizard@latest -i nextjs
```
03
Vite + React: install @sentry/react and call Sentry.init in a file such as instrument.js that your entry file imports first. On React 19, pass Sentry.reactErrorHandler() to the onUncaughtError, onCaughtError and onRecoverableError options of createRoot; on React 18 or below, wrap the app in Sentry.ErrorBoundary. Sentry's React guide is for client-side apps, so server code you deploy next to the app, such as Vercel Functions, needs its own setup from the guide for its runtime.
```
npm install @sentry/react --save
```
04Put the DSN in an environment variable: NEXT_PUBLIC_SENTRY_DSN for Next.js, as Sentry's manual setup suggests, or VITE_SENTRY_DSN for Vite, which exposes only VITE_ variables to client code. Set it in Vercel for both Production and Preview, then redeploy, because Vercel applies variable changes to new deployments only. Sentry gives each project one DSN. It only lets clients send events, so it is safe in browser code, and an SDK started with an empty DSN sends nothing.
05
Set environment yourself so preview and production errors stay apart. Sentry's JavaScript option reference says the default is development or production depending on packaging; it does not establish a preview tag for your deployment. Alert rules can filter on the environment tag. In Next.js, use NEXT_PUBLIC_VERCEL_ENV, which Vercel sets to production, preview or development, in all three init files. In a Vite app, add your own VITE_SENTRY_ENVIRONMENT variable in Vercel: production for Production, preview for Preview.
```
Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NEXT_PUBLIC_VERCEL_ENV,
});
```
06Give each deployment one release name, such as the commit SHA that Vercel provides at build time as VERCEL_GIT_COMMIT_SHA. Sentry's release docs say a release is also created on its own when source maps upload or when an event names a new release, so pick the name when you build. For Next.js, Sentry's release guide says to set the SENTRY_RELEASE environment variable so source maps are associated with the right release. For Vite, pass the name to release in Sentry.init from a VITE_ variable set in the build command, such as VITE_SENTRY_RELEASE=$VERCEL_GIT_COMMIT_SHA vite build.
07
Upload source maps from the production build, in CI or through Sentry's Vercel integration. Next.js: withSentryConfig uploads them on next build when SENTRY_AUTH_TOKEN is set where the build runs, and deletes the client source maps after upload by default. Vite: run the source map wizard, or add @sentry/vite-plugin as the last plugin with build.sourcemap set to "hidden" and sourcemaps.filesToDeleteAfterUpload, because generated source maps can expose your code. Neither uploads from a dev server, so test with a production build. Linking projects in the Vercel integration sets SENTRY_AUTH_TOKEN, SENTRY_ORG, SENTRY_PROJECT and NEXT_PUBLIC_SENTRY_DSN in the Vercel project; redeploy afterwards.
```
npx @sentry/wizard@latest -i sourcemaps
```
08Decide what user data to send for the installed SDK version. The dataCollection option is available from JavaScript SDK 10.57.0. In v10 its defaults apply only when you set that option; otherwise sendDefaultPii controls collection. In v11 those defaults always apply. They include user identity, HTTP bodies and URL query parameters, with sensitive key names filtered. Configure only the data your app needs. userInfo: false disables automatically collected identity, but does not remove data explicitly set with Sentry.setUser(). Session Replay has separate privacy controls. Inspect a test event with synthetic data before enabling collection for users.
09Add one alert rule. In Sentry, open Monitors, then Alerts, and click Create Alert. Pick your project as the source, set the environment to production, choose the triggers A new issue is created and A resolved issue regresses, and send them to email or a Slack channel. Click Send Test Notification to check the channel before you save, since a preview test error does not match a production-only rule.
10Throw one test error on a preview deployment from the browser and one from a server route, confirm both arrive with readable stack traces and the preview environment, then promote with release and environment tags. Throw them from the app, not from the browser console: Sentry's guides say errors triggered from developer tools are sandboxed and do not reach Sentry. The procedure and what you should see are below.

Proposed manual check

Throw two test errors on a preview

This is a proposed manual procedure built from Sentry's docs, not an observed customer result. Use a preview deployment of your own app, a Sentry project you own and no customer data. A pass shows that one browser error and one server error from one deployment reach one project with readable stack traces, not that every error path is covered.

Browser error

Next.js: open /sentry-example-page on the preview URL and click Throw Sample Error. Vite + React: add this button from Sentry's React guide to a page, deploy to a preview and click it. Sentry's guides say you should then see the error in Issues with a stack trace pointing at your source code.

<button
  type="button"
  onClick={() => {
    throw new Error("Sentry Test Error");
  }}
>
  Break the world
</button>

Server error

Next.js: add a route handler that throws, deploy it to the same preview and open its URL. Sentry's Next.js guide lists server errors that crash API routes among the errors it captures without extra code; an error you catch and do not rethrow needs Sentry.captureException. The force-dynamic line keeps Next.js from running the handler at build time. In a Vite app, test the server side with the guide for the runtime it runs on. Remove the test route before you promote.

// app/api/sentry-test/route.ts
export const dynamic = "force-dynamic";

export async function GET() {
  throw new Error("Sentry server test error");
}

Read the result

What Sentry Issues shows, and what to fix
What you see	What to fix
Both errors, with stack traces in your own files and the preview environment	This monitoring check passed. Remove the test route and finish your other release checks before promoting.
No events at all	The DSN is missing from the Preview variables, or the deployment was built before you added it (step 4)
The browser error with minified bundle frames	Source maps did not upload: check SENTRY_AUTH_TOKEN where the build runs (step 7)
Only the browser error	Server init is not running: check instrumentation.ts and sentry.server.config.ts (step 2)
Only the server error, and a blocked request in the browser network panel	A browser blocker stopped it. Test with blockers off; Sentry documents a tunnel route for production traffic
Both errors under the production environment	environment is not set from the deployment (step 5)

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

How do I set up Sentry for an AI-built app?

Check for existing Sentry code first, then run npx @sentry/wizard@latest -i nextjs for Next.js, or install @sentry/react for a Vite + React app. Set the DSN for Production and Preview in Vercel, set environment and release, upload source maps from the production build, add one alert rule, and test with one browser error and one server error on a preview.

Why are source maps important for Sentry?

Production JavaScript is minified, so without source maps a stack trace points at bundle files instead of your code. They upload during the production build, not from a dev server. If traces still show minified code, check that SENTRY_AUTH_TOKEN is set where the build runs.

Is it safe to put the Sentry DSN in browser code?

Yes. Sentry says a DSN only lets clients send new events and gives no read access, and you can rotate it in the project's Client Keys settings. The auth token for source map uploads is different: keep it in the build environment, never in a NEXT_PUBLIC_ or VITE_ variable.

Why does a test error from the browser console not show up in Sentry?

Sentry's guides say errors triggered from the browser developer tools are sandboxed and do not reach Sentry. Throw the test error from a button or a route in the app instead.