> ## Documentation Index
> Fetch the complete documentation index at: https://docs.auto.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Runtime Sentry telemetry

> Configure and verify Sentry errors, tracing, and source maps for the auto platform's Vercel and Cloudflare runtimes.

auto's platform repository instruments its Vercel web app, Session Bridge Worker and `SessionDO`, and Datadog Tail Worker with Sentry. Use this guide when operating those services; it does not configure telemetry for arbitrary agent sandboxes or install the separate [Sentry issue-triage managed template](/reference/managed-templates#sentry-issue-triage).

<Note>
  Merged instrumentation is not proof of deployment or live ingestion. Each runtime needs its DSN, source-map uploads need build credentials, and activation requires a separately authorized deployment. Without a DSN, the corresponding Sentry SDK is disabled.
</Note>

## Collection and tracing

The web app captures errors at framework and project error boundaries and enables browser navigation tracing. The Session Bridge wraps its Worker and Durable Object; the persisted `SessionDO` binding name and storage migrations are unchanged. The Tail Worker also captures handled Datadog delivery failures and waits for asynchronous delivery before its Sentry wrapper flushes.

The configured trace sample rate is `1` for environment `development` and `0.1` otherwise. Node shares Vercel's OpenTelemetry provider rather than installing a second provider, retaining its automatic Datadog exporter and Postgres instrumentation. When Sentry is configured, its sampler applies to that shared provider, including traces exported to Datadog.

The shared SDK policy sets `sendDefaultPii: false` and disables automatic collection of user information, cookies, request/response headers and bodies, URL query parameters, model inputs/outputs, GraphQL documents/variables, database query data, and stack-frame locals. The Next.js request-error hook also removes query strings and fragments from the captured request path. Session replay, Sentry log intake, and profiling are not enabled by this integration.

Sentry's export callbacks additionally replace the bot-token segment in `https://api.telegram.org/bot<TOKEN>/...` and `https://api.telegram.org/file/bot<TOKEN>/...` with `[Filtered]`. This covers span names and attributes, transaction metadata, error messages, and breadcrumbs. Relative `http.target` and `url.path` fields are filtered only when accompanying attributes identify Telegram's host. Filtering copies serialized telemetry; it does not redact the original OpenTelemetry spans used by other exporters.

<Warning>
  Error messages and stacks are still sent. Automatic-collection settings do not scrub externally instrumented OpenTelemetry attributes, and the Telegram-specific filter is not a general secret detector. Other providers' URLs and paths remain intact; query strings supplied by Vercel instrumentation, including signed private-asset URLs, are still forwarded. Custom error text and manually supplied event data can also contain sensitive information.
</Warning>

Trace-propagation targets match complete configured origins, not hostnames embedded inside unrelated URLs:

| Runtime                  | Configured propagation targets                                                                                                  |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| Browser                  | Same-origin relative requests and the current page origin.                                                                      |
| Web Node                 | Origins from `AUTO_SESSION_BRIDGE_URL`, `AUTO_MODEL_GATEWAY_CLOUDFLARE_URL`, and `AUTO_WEB_BASE_URL`.                           |
| Session Bridge           | Origins from `AUTO_WEB_BASE_URL`, `AUTO_CODEX_EGRESS_URL`, and `https://session-do.internal`; RPC trace propagation is enabled. |
| Web Edge and Tail Worker | Empty HTTP propagation target lists.                                                                                            |

Keep the configured URL variables pointed at first-party services; these settings do not enable propagation to third-party model APIs.

## Configure the web app

Use one Sentry project for the browser, Node, and Edge runtimes. Set these variables in the intended Vercel deployment environment:

| Variable                                       | Purpose                                                                                    |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `NEXT_PUBLIC_SENTRY_DSN`                       | Browser ingestion DSN and the Node/Edge fallback.                                          |
| `SENTRY_DSN`                                   | Optional explicit Node/Edge DSN for the same project.                                      |
| `SENTRY_ORG`, `SENTRY_PROJECT`                 | Organization and web project for source-map uploads.                                       |
| `SENTRY_AUTH_TOKEN`                            | Build-only source-map upload credential.                                                   |
| `SENTRY_ENVIRONMENT`                           | Node/Edge environment override; otherwise `VERCEL_ENV`, then `NODE_ENV`.                   |
| `NEXT_PUBLIC_SENTRY_ENVIRONMENT`               | Browser environment override; otherwise `NEXT_PUBLIC_VERCEL_ENV`, then `NODE_ENV`.         |
| `SENTRY_RELEASE`, `NEXT_PUBLIC_SENTRY_RELEASE` | Optional server and browser release overrides; set both to the same value when overriding. |

Node and Edge default their release to `VERCEL_GIT_COMMIT_SHA`; the Sentry build plugin supplies the matching browser release. Rebuild the web app after changing public configuration. A DSN is a public ingestion identifier, but the upload token must never use a `NEXT_PUBLIC_` prefix or be included in client configuration.

The Next.js build uses `withSentryConfig` to upload source maps when `SENTRY_AUTH_TOKEN` is present and delete maps after upload. Without the token, automatic source-map upload is disabled; configuring an ingestion DSN alone does not enable uploads.

The web build's `apps/web/turbo.json` explicitly passes its Sentry settings, `VERCEL_ENV`, and `VERCEL_GIT_COMMIT_SHA` through Turbo's strict environment. These values participate in the build cache key, so adding an upload token or changing the project or release invalidates output built with the old settings. The token is scoped to the web build task. If the token is configured in Vercel but the build reports `No auth token provided`, check this task's environment allowlist. After confirming an upload, verify a newly generated error event.

## Configure the Workers

Use a separate Sentry project for Session Bridge and its Durable Object, and another for the Tail Worker. Both Worker bundles are named `index.js`; separate projects keep release-based source maps associated with the correct service.

Store each Worker's `SENTRY_DSN` in that Worker's secret binding for the intended deployment environment. For local Workers, use the app's ignored `.dev.vars` file. These bindings are runtime configuration, not an agent [provider connection](/reference/tools).

| Runtime                        | Service tag                | Environment fallback                                       | Release fallback                                     |
| ------------------------------ | -------------------------- | ---------------------------------------------------------- | ---------------------------------------------------- |
| Session Bridge and `SessionDO` | `auto-session-bridge`      | `SENTRY_ENVIRONMENT`, then `NODE_ENV`, then `development`. | `SENTRY_RELEASE`, then `SESSION_BRIDGE_RELEASE_SHA`. |
| Tail Worker                    | `auto-cloudflare-log-tail` | `SENTRY_ENVIRONMENT`, then `DD_ENV`.                       | `SENTRY_RELEASE`, then `DD_VERSION`.                 |

The deployment materializer supplies the selected Git SHA to both release fallback fields. Leave `SENTRY_RELEASE` unset in production so runtime events match source maps uploaded under that SHA.

### Production source-map uploads

Configure the existing GitHub production deployment workflow with repository variables `SENTRY_ORG`, `SENTRY_PROJECT_SESSION_BRIDGE`, and `SENTRY_PROJECT_CLOUDFLARE_LOG_TAIL`, plus repository secret `SENTRY_AUTH_TOKEN` authorized to upload to both projects.

When the workflow selects a Session Bridge deployment, it deploys the Tail Worker and then Session Bridge with `--outdir dist`. Each following Sentry upload uses that app's saved bundles and the selected release SHA. An upload step runs only when its corresponding project variable is nonempty; a configured upload failure fails the workflow.

For first activation, configure the upload variables and credentials before the Worker deployment and verify both source-map uploads before enabling ingestion through the runtime DSNs. Adding upload settings afterward does not backfill maps: a workflow rerun can skip already-deployed code. Use the next deployment with changed Worker inputs, or a separately authorized upload of the exact deployed bundles and release.

Both Wrangler configurations enable `upload_source_maps`, but uploading maps to Cloudflare does not upload them to Sentry. For a separately authorized manual deployment, run the equivalent Sentry upload from the deployed app's directory, using its matching project credentials, saved `dist` output, and exact deployed SHA as `SENTRY_RELEASE`:

```sh theme={null}
npx --no-install sentry-cli sourcemaps upload --release "$SENTRY_RELEASE" --strip-prefix dist/.. dist
```

## Verify activation

Repository tests exercise local SDK envelopes, including web errors, Tail Worker delivery failures, and Worker fetch, Durable Object fetch, and real alarm errors under workerd. Those tests and successful compilation do not establish live Sentry ingestion.

After separately authorized configuration, use local or preview instances to exercise temporary errors in a browser event handler, Next.js server route, Worker fetch handler, Durable Object handler, and Tail Worker delivery. Remove the temporary triggers afterward. Through authenticated Sentry access, record each issue's URL, title, message, environment, release, and readable source frames; also verify a browser-to-web-to-bridge trace.

Keep source validation, deployment completion, and authenticated ingestion evidence separate. Do not report production telemetry as active from a merge, a captured local test envelope, or source-map configuration alone.