Error tracking

apps/web reports errors to Sentry through @sentry/nextjs. No other app reports: apps/agent, apps/console, apps/marketing, apps/docs and apps/help have no Sentry SDK, so an error there reaches only the Vercel runtime logs.

Configuration

Three variables, all declared in turbo.json → globalEnv:

Variable	Read by	Used for
`SENTRY_DSN`	`sentry.server.config.ts`, `sentry.edge.config.ts`	Where the Node.js and edge runtimes send events
`NEXT_PUBLIC_SENTRY_DSN`	`instrumentation-client.ts`	Where the browser sends events
`SENTRY_AUTH_TOKEN`	`withSentryConfig` in `next.config.ts`, at build time only	Authenticating the build against the Sentry project

Each event is tagged with its environment from VERCEL_ENV (server and edge) or NEXT_PUBLIC_VERCEL_ENV (browser), so production and preview events stay apart. The Sentry organisation is sustentus-q7 and the project is sustentus-web.

With no DSN set — a local run without .env.local, for instance — the SDK initialises and sends nothing.

What is captured

Server and edge request errors. instrumentation.ts loads the runtime’s config and exports onRequestError = Sentry.captureRequestError, so a crash in a Server Component, route handler or server action reaches Sentry. Next.js catches those before any other hook sees them.
Error boundaries. app/error.tsx and the shared components/segment-error boundary report through one hook, hooks/use-boundary-retry.ts, which logs the error to the console and calls Sentry.captureException; app/global-error.tsx (errors that escape the root layout) calls Sentry.captureException itself.
Explicit reports. Code that detects a state it cannot recover from calls Sentry itself — for example, the figure bridge card reports a bridge that does not reconcile with Sentry.captureMessage, fingerprinted by figure.
Traces. 10% of requests are sampled (tracesSampleRate: 0.1) in every runtime.
Session Replay, in the browser only, and only around an error: replaysSessionSampleRate: 0, replaysOnErrorSampleRate: 1.0. Replay’s defaults stay on — all text masked, all media blocked.
No personal data by default. The client config passes no dataCollection object, which keeps sendDefaultPii off.

Browser events go through the /monitoring tunnel route (tunnelRoute in next.config.ts), so ad blockers that block Sentry’s own domain do not drop them. proxy.ts excludes /monitoring from its matcher.

Known limits

Source maps are off. sourcemaps: { disable: true } and buildTimeInstrumentation: false keep next build inside the memory of Vercel’s standard build machine, so stack frames in Sentry are minified. Turning them back on is parked as .icm/intake/triage/sentry-source-maps-back-on-web.md.
Library spans are off for the same reason: traces carry requests, not automatic database or library spans.

Where to look

Sentry: the sustentus-web project, filtered by environment.
A user’s report: the error page shows a Reference — Next.js’s error digest. The same digest is on the server’s log line for the error and on the Sentry event, so it joins a screenshot to both.
Other apps: Vercel’s runtime logs for that project.