Add Error Monitoring to Any AI-Built Website or Web App With Sentry

Describe Your App

Instead of waiting for a user to report a broken feature, Sentry records the error when it happens — with the page, the code and the version involved.

Plan Your Error Monitoring

Describe your app and what matters most, and let AI turn it into a short monitoring plan before anything is installed.

I want to add error monitoring with Sentry to this existing website or web app. When real users hit an error, Sentry should record what broke, where it happened and enough context to fix it — instead of me waiting for someone to report it. What the app does: {{APP}} Whether it is live yet: {{LIVE}} What Sentry should watch most closely: {{FOCUS}} Whether it uses Supabase: {{SUPABASE}} Server code or Edge Functions: {{SERVER}} Do not change any files, and do not install anything. This task only plans the monitoring. Look through the project only enough to use its real names — its pages, features and functions — so the plan describes this app rather than a generic example. Do not audit the code yet. That is the next step. Turn my answers into a short monitoring plan in plain words, with exactly these parts: 1. Frontend: what Sentry should catch in the pages people use — for example, unexpected crashes and errors anywhere in the app 2. Important flow: the flow that needs extra attention, and what a failure there looks like — or "none beyond the whole app" 3. Backend: which server code or Edge Functions to watch, if the project has any — or "none" 4. Supabase: whether failed Supabase requests should be reported — or "not used" 5. Live vs testing: how errors from the live site will be kept apart from errors on my own computer 6. Stays out: the private information that must never be sent to Sentry for this app, such as passwords, sign-in tokens, payment details or private form content 7. Alerts: which new problems should notify me, and how — without an alert for every small error Rules: - Use plain words. Do not assume I know Sentry's terms. - Monitor only the parts this project really has. Never plan monitoring for a backend, a framework or a service it does not use. - This is error monitoring only. Do not plan Session Replay, performance tracing, profiling or feedback widgets. - If my answers conflict with what you see in the project, say so instead of guessing. Finish with the plan as a compact list I can copy and keep. Then wait for my approval. Do not implement anything.

What does your website or web app do?

A booking app where customers pick a time slot and pay a deposit.

Is it live yet?

What should Sentry watch most closely?

Does it use Supabase?

Does it have server code or Edge Functions?

Adjust the plan with the AI until it matches what you care about, and keep this conversation open — every later prompt builds on it. If you ever start a new conversation, paste the plan in first.

Approve the Monitoring Plan

You should now know what Sentry will watch, what it will never receive, and when it will alert you.

The plan covers the whole app, plus the flow I care about most

It names backend code to watch only if my project really has it

It lists the private information that must never reach Sentry

I saved a copy of the final plan

Inspect Your Project

Nothing changes in this step. The AI maps your real stack and picks exactly one official Sentry SDK for each part that exists.

Check the Project

Let AI find your framework, error handling, backend, Supabase use and build setup, then choose the right Sentry setup before anything changes.

Using the monitoring plan we just approved, inspect this project before anything is installed. Do not change any files and do not install anything in this task. If the approved plan is not in this conversation, STOP and ask me to paste it. Find and report: - The framework and build system, with versions — for example React with Vite, Next.js, or another setup - The frontend entry points, and the React version if it is a React app - Existing error boundaries and error pages - Existing error handling and logging: try/catch blocks, error messages shown to users, logging helpers - Places where errors are swallowed — caught and ignored, or only printed with console.error — especially in the important flow from the plan - Server code and API routes, and which runtime they use - How the app uses the Supabase client, if it does, and which version of supabase-js - Supabase Edge Functions, if the project has any, and which ones matter for the plan - How environment variables work here: the file names, the prefix the frontend needs, and which values are public - Where and how the app is deployed, and how its production build runs - Whether the production build creates source maps today, and whether they are published - Whether Sentry, or another error-monitoring tool, is already partly installed - Anything that looks like a secret — API keys, tokens, service-role keys — in frontend code. List names and files only, never the values. Then give me a short plan: 1. What should be monitored, mapped to real files and functions 2. Which official Sentry SDK fits each part that exists — exactly one per runtime — for example @sentry/react for a React app, @sentry/nextjs for Next.js, @sentry/node for a Node server, or the Sentry Deno SDK for Supabase Edge Functions 3. Which parts of the project need changes 4. Which environment variables are needed, which are public and which must stay private 5. Whether server or Edge Function monitoring is needed, and for which functions 6. Implementation plan: the smallest set of changes, in order Rules for the plan: - Use the current official Sentry setup for this real stack. Check Sentry's current documentation instead of relying on memory — SDKs and setup steps change. - Never plan two overlapping SDKs for the same code. If Sentry is already partly installed, extend it. If another monitoring tool already does this job, tell me before adding Sentry. - Keep the existing error handling that works. Only add reporting where errors are unexpected or currently swallowed. - Plan nothing for runtimes the project does not have. Wait for my approval before changing anything.

Approve the Plan

Approve the plan once it fits your real stack and nothing more.

The plan names one official Sentry SDK for each part my project really has

It lists which environment variables are public and which stay private

It keeps my existing error handling that already works

It adds nothing for runtimes my project does not use

Create Your Sentry Project

Sign in to Sentry, or create an account Create a new project for the platform the AI named — for example React or Next.js Copy the DSN from the setup instructions Sentry shows

You can find the DSN again any time in your project's settings:

Settings Projects Your project Client Keys (DSN)

The DSN only lets your app send errors to this project, so it is fine in frontend code. It is not a password.

Expected result

You have a Sentry project for your app and its DSN.

Connect the Frontend

The AI installs the right Sentry SDK and catches unexpected errors everywhere in your app.

Connect the Frontend to Sentry

Install the official Sentry SDK for your framework, tag live and local errors apart, and add a friendly error screen — with no Session Replay or tracing.

Now connect the frontend to Sentry, following the approved plan. My Sentry project exists, and I will give you its DSN when you ask. If the approved plan is not in this conversation, STOP and ask me for it. Set up: - Install the official Sentry SDK the plan chose for the frontend, and initialize it at the app's entry point, following Sentry's current documentation for this framework. If you use Sentry's setup wizard, decline Session Replay, tracing, logs and example pages. - Read the DSN from the framework's normal public configuration — for example a VITE_ or NEXT_PUBLIC_ environment variable. The DSN is meant to be public: it only lets the app send errors to my project. - Set the environment from the build — production for the live site, development on my computer, and staging or preview where the project has one — so live errors are easy to tell apart - If the build or deployment already provides a version cleanly — a commit SHA or the package version — send it as the release. Do not build a release process just for this. - Capture unhandled errors and unhandled promise rejections everywhere in the app - Add an error boundary with a friendly fallback where the app benefits from one, using Sentry's pattern for this framework — for example Sentry's React 19 root error handlers, Sentry's ErrorBoundary for older React, or the framework's own error page for Next.js. If the app already has a good error boundary, connect it to Sentry instead of replacing it. - Keep the defaults that avoid personal data: do not turn on sendDefaultPii - Do not add Session Replay, performance tracing, profiling, logs or a feedback widget A Sentry auth token, organization token or any other management credential must never go in frontend code, a public environment variable or the repository. Nothing in this task needs one. Then add ONE temporary way to send a test error from local development only — for example a button that appears only in development — and tell me exactly how to trigger it. Give me: 1. What you installed and changed, and where 2. The environment variable to set, and where to set it — locally and in my hosting settings 3. How to trigger the local test error, and what I should see in Sentry Run the project's build afterwards.

Give the AI your DSN when it asks Add the environment variable on your computer and in your hosting settings Let the AI finish the changes and the build

Expected result

Sentry is installed in your app, and the AI has told you how to send a test error.

Send a Local Test Error

Run the app on your computer and trigger the test error Open Issues in Sentry Open the new issue and check that it is marked as development

Expected result

The test error appears in Sentry within a minute or two, marked as development.

Add Backend Monitoring

Only for what your project really has: the Supabase client, Edge Functions or another server. A browser-only app skips most of this.

Monitor Backend Errors

Report failed Supabase requests, Edge Function crashes and server errors — while users keep getting safe error messages.

Now add monitoring to the backend parts the approved plan named. Change only what exists. If the approved plan is not in this conversation, STOP and ask me for it. If the project has no Supabase client and no server code, tell me there is nothing to add in this step, and stop. Use the same Sentry project and DSN as the frontend unless the plan says otherwise. Supabase client — if the app uses supabase-js: - If the installed Sentry SDK supports it, add Sentry's official Supabase integration, Sentry.supabaseIntegration, to the existing Sentry setup, so failed Supabase requests are reported with a trail of recent database operations. Update the Sentry SDK first if it is too old. Do not use an older community package for this. - supabase-js returns most errors instead of throwing them. Where the app receives an unexpected Supabase error and ignores it or only logs it, report it to Sentry — but not errors the app already expects and handles, such as an email that is already registered. - Check Sentry's current documentation for whether the integration needs tracing turned on. If it does, use a low sample rate, and send trace headers only to my own app and my Supabase project, never to other domains. If it does not, leave tracing off. Supabase Edge Functions — only the ones the plan named: - Use the current Sentry Deno SDK, following Supabase's current guide for Sentry in Edge Functions - Read the DSN from an Edge Function secret, for example SENTRY_DSN - A warm Edge Function serves many requests, and the Deno SDK does not keep them apart on its own. Turn off the default integrations as the guide shows, and keep each request's reporting in its own scope — never set user details, request data or breadcrumbs globally, or one user's details could appear in another user's error. - Capture unexpected exceptions, then flush Sentry with a short timeout before the function returns - Do not add tracing or profiling Other server code — Node, API routes or another backend: - Use the official Sentry SDK for that runtime and framework, set up the way Sentry's current documentation says - Capture unexpected exceptions in the request handlers that matter Error handling rules for every backend: - Keep returning the same safe, useful error responses to users. Never turn a handled error into a crash just so Sentry can see it. - Report the internal error to Sentry, and keep stack traces, internal details and secrets out of every user-facing response - Do not report expected outcomes — validation failures, not found, not signed in, permission denied — as errors Then add ONE temporary, controlled way to trigger a backend test error — for example a test-only branch in one function that runs only when a clearly temporary flag is sent — and tell me exactly how to trigger it and how it will be removed later. Give me: 1. What you changed, per runtime — or that there is nothing to add 2. Any secret or environment variable to set, and where 3. How to trigger the backend test error, and what I should see in Sentry Deploy the Edge Functions you changed, and run the project's build afterwards.

If your project uses Supabase Edge Functions, add the DSN here under the name the AI gave you:

Edge Functions Secrets

Expected result

The AI has added backend monitoring where it matters, or confirmed there is nothing to add.

Send a Backend Test Error

Skip this if the AI found no backend to monitor.

Trigger the backend test the way the AI described Open Issues in Sentry and find the backend error Check that the response shows a safe message, not the internal error

Expected result

The backend test error appears in Sentry, while the response to the user stays safe.

Add Context and Filter Private Data

Enough context to fix each error, nothing private, and no noise from errors your app expects.

Make Error Reports Useful and Safe

Add the page, feature and version to every error, strip passwords, tokens and private input, and stop expected errors from flooding Sentry.

Now make the error reports useful and safe. Inspect the Sentry setup we built, and change only what is missing. If the approved plan is not in this conversation, STOP and ask me for it. Useful context — add it where it helps: - The environment and release on every event, in the frontend and every backend part - The route or page where the error happened - A feature tag for the important flow from the plan — for example feature: checkout - The signed-in user's internal ID only, and only if it helps and the app's privacy policy allows it. Never an email address, name or phone number. - Safe action context, such as which button or request failed — never its private contents Keep private data out. Check every way data reaches Sentry — errors, breadcrumbs, request data, URLs and extra context — for: - Passwords, sign-in tokens, session cookies and Authorization headers - API keys and other secret headers - Payment details - Database credentials - Full form contents where they are private - Private AI prompts and responses, unless I explicitly decide otherwise - Tokens inside URLs — for example the access token some sign-in links put after a # in the address Keep sendDefaultPii off. Use Sentry's beforeSend and beforeBreadcrumb hooks to remove or mask anything above that could still get through, and tell me which data-scrubbing settings to check in my Sentry project. Expected errors — do not report these as issues: - Form validation, wrong passwords and other input mistakes - Expected not-found pages - A user cancelling an action, and requests aborted by navigation - Permission denied where it is intended - Known harmless browser noise — ignore only specific, named messages, never broad patterns that could hide real failures Session Replay stays off. Do not add it. Give me: 1. What context each event now carries 2. What is filtered, and where 3. What is no longer reported, and why each one is safe to ignore Deploy any Edge Functions you changed, and run the project's build afterwards.

Expected result

Each error now shows where it happened and in which version, and nothing private is sent.

Upload Source Maps

Turns unreadable live stack traces back into your real file names and lines.

Set Up Source Maps

Upload source maps from your production build with a private token, so live errors point to real code — without publishing the maps.

Now set up production source maps, so an error in the minified live code points to the real file and line. If the approved plan is not in this conversation, STOP and ask me for it. If the project has no build step that minifies code, tell me no source maps are needed, and stop. - Use Sentry's official build plugin or tool for this build system, following Sentry's current documentation — for example the Sentry Vite plugin for a Vite app, or the Next.js SDK's built-in upload - Create source maps during the production build, upload them to Sentry, and make sure visitors cannot download them — for example hidden source maps that are deleted after upload - The upload needs a Sentry auth token. Read it only from the build environment — SENTRY_AUTH_TOKEN in my hosting or CI build settings, or a local file that is git-ignored. Never put it in frontend code, a public environment variable or the repository, and never ask me to paste it into this conversation. - Tie the uploaded source maps to the same release the app reports, if the plan uses releases - If my hosting cannot keep a private build variable, tell me and suggest the simplest safe alternative, instead of weakening the rule Give me: 1. What you changed 2. The exact build environment variables to set, and where — without their values 3. How I will know the upload worked Run a production build afterwards, and confirm that no .map file ends up in the files that get deployed and that the auth token appears in no built file.

If the AI asks for an auth token, create an organization token here:

Settings Developer Settings Organization Tokens

Keep the auth token private

Unlike the DSN, this token can change your Sentry organization, and Sentry shows it only once. Add it only to your hosting or CI build settings, or a git-ignored local file — never to frontend code, a public variable, the repository or the AI conversation.

Expected result

Production builds upload source maps to Sentry, and no .map file is published with your site.

Turn On a Production Alert

Get told about new problems without checking Sentry all day.

Monitors Alerts

Select Create Alert and choose an alert for issues Set it to trigger when a new issue is created Filter it to the production environment Choose where to be notified, such as email or Slack

If your project already has an issue alert, adjust that one instead of adding a second.

Expected result

One alert tells you when a new production issue appears — not every time an old one repeats.

Test on the Live Site

A controlled test error that only you can trigger proves the whole chain works.

Test Error Monitoring

Trigger controlled test errors on the live site and check environment, stack traces, source maps, private data, alerts and safe error messages.

Help me prove error monitoring works on the live site. Installing Sentry is not enough — test the real flow. If the approved plan is not in this conversation, STOP and ask me for it. If the app is not live yet, tell me which of these tests must wait until it is. Set up a controlled test: - One temporary test error in the frontend and, if the project has backend monitoring, one in the backend - Each one fires only when I trigger it on purpose — for example with a one-off URL parameter only I know — and never for normal visitors - The frontend test shows the app's normal friendly error state, never a blank page or internal details - Deploy them, and tell me exactly how to trigger each one Walk me through these tests, and tell me what to check for each: 1. The test error appears in Sentry 2. It is tagged with the production environment 3. Its stack trace points at useful application code 4. Source maps show real file names and lines for the production code, where configured 5. The page, route or feature is visible on the event 6. A real frontend error is captured 7. A backend or Edge Function error is captured, where the project has backend monitoring 8. A normal validation error does not create a Sentry issue 9. No secret or API key is visible anywhere in the captured events 10. No sign-in token, cookie or Authorization header is visible 11. No unnecessary private user input is visible 12. The alert notification arrives, if an alert is configured 13. The user sees a safe error message, not internal details 14. The app's existing features still work Report expected versus actual for every test, then finish with exactly one verdict: MONITORING READY or NEEDS ATTENTION If NEEDS ATTENTION, list only what is still failing. Once MONITORING READY, remove every temporary test error and test trigger — including the local and backend ones from earlier steps — and search the project to confirm none remain. Never leave code that deliberately crashes the app. Run the build, and tell me to deploy the cleanup.

Continue when the AI reports MONITORING READY. If it reports NEEDS ATTENTION, fix the listed issues and run the test again.

Remove the Test Errors

Never leave a deliberate crash in a live app.

Let the AI remove every test trigger and confirm none remain Deploy the cleanup Resolve the test issues in Sentry

Expected result

No test error remains in your app, and the cleanup is live.

Your app now reports real production errors to Sentry, giving you the context you need to find and fix problems users actually encounter.