All use cases

Sentry Error Monitoring

Full observability setup.

PipelinesAgent: claude
Integrated Services
Sentry
Required Configuration

This use case works best with the following environment variables, which are injected into your sandbox at runtime:

SENTRY_DSNSENTRY_AUTH_TOKENSENTRY_ORGSENTRY_PROJECT
Prompt
Set up comprehensive error monitoring with Sentry in a Next.js app: 1. Sentry SDK initialization with source maps upload 2. Custom error boundary component with user-friendly fallback UI 3. Server-side error capture in API routes and middleware 4. Performance monitoring with custom transactions for key flows 5. User feedback dialog on error (Sentry Feedback widget) 6. Release tracking with commit association 7. Environment-based DSN configuration (dev/staging/prod) Follow Sentry Next.js integration best practices with the @sentry/nextjs package.
Use this

Why this exists

The worst way to find out your app is broken is a user telling you. Most teams bolt on error tracking after the first outage, then discover their stack traces are minified nonsense because nobody uploaded source maps. Sentry solves all of it, but a real Next.js setup reaches into the client, the server, the build step, and your release process, and half of those are easy to configure wrong. This blueprint installs the whole thing correctly, as code in your repository.

What the agent builds

A full observability setup on @sentry/nextjs. The SDK is initialized across client and server with source maps uploaded at build time, so stack traces point at your real code instead of minified junk. It adds a custom error boundary with a friendly fallback screen, server-side capture in API routes and middleware, performance monitoring with custom transactions on key flows, and the Sentry user-feedback dialog so people can describe what broke. Releases are tracked with commit association, and the DSN is set per environment for dev, staging, and prod.

You watch it happen in the task workspace: the agent scaffolds the config, wires the boundary and server capture, sets up releases and per-environment DSNs, and throws a test error to confirm it lands in Sentry with a readable trace. The code lands on a branch in your repository with a pull request ready.

Make it yours

The first version is a solid baseline you steer with plain follow-up messages:

  • "Alert my Slack channel when a new error type appears."
  • "Scrub email addresses out of events before they send."
  • "Wrap the checkout flow in its own custom transaction."
  • "Ignore that noisy third-party script error."

Each follow-up wakes the same repository and the agent continues on its own code.

FAQ

Do I need a Sentry account? Yes, it runs on your own Sentry DSN and project, so your error data stays under your account.

Why do source maps matter? Without them, stack traces show minified code. Uploading them at build time means every error points back at your actual source.

Will monitoring slow my app? Performance tracing samples a fraction of traffic, and you can tune the sample rate per environment to keep overhead low.

Sentry Error Monitoring | OutcomeDev Use Cases