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.
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.
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 persistedSessionDO 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.
Trace-propagation targets match complete configured origins, not hostnames embedded inside unrelated URLs:
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:
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 namedindex.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.
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 variablesSENTRY_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: