Debug Sentry in Chrome DevTools

What Sentry traffic looks like

Sentry's browser SDK ships errors and performance data as "envelopes" to an ingest endpoint derived from the project's DSN.

Endpoint pattern

o<org-id>.ingest.sentry.io/api/<project-id>/envelope/. Older SDKs used a /store/ endpoint; self-hosted and tunneled setups proxy the same envelopes through a first-party path; the SDK itself often loads from browser.sentry-cdn.com when installed via the loader snippet rather than bundled

Transport

POST of newline-delimited JSON. The first line is a header (event ID, DSN, SDK version); subsequent lines are typed items: event for exceptions, transaction for performance traces, session, and replay_event

Key parameters

sentry_key: the public key in the query string, identifying the project

Payload

An error event carries the exception with stack trace, breadcrumbs (recent console logs, clicks, fetches), user context if the site set one, release, environment, and tags. This is why Sentry matters in a tracking audit despite selling no ads: breadcrumbs and user context can carry URLs, form state, and identifiers the privacy team never reviewed

An error envelope, as Event Watcher captures it:

{ "event_id": "9f2e47…", "dsn": "https://abc123@o12345.ingest.sentry.io/67890", "sdk": { "name": "sentry.javascript.browser", "version": "8.9.0" } }
{ "type": "event" }
{ "exception": { "values": [{ "type": "TypeError", "value": "Cannot read properties of undefined" }] }, "breadcrumbs": [{ "category": "ui.click", "message": "button.add-to-cart" }], "user": { "email": "user@example.dk" }, "release": "web@2.14.0" }

Debugging Sentry with Event Watcher

• Matches the .ingest.sentry.io and sentry.io/api endpoints plus the browser.sentry-cdn.com SDK load, names them as Sentry, and files them under the monitoring category. Observability traffic is visibly separated from marketing pixels in the stream.
• No dedicated parser: you get the raw request with its parsed query parameters (sentry_key identifies the project) and body, the cookies sent, and the consent verdict per event.
• Grouped view by Tool collects all Sentry envelopes in one place, making volume obvious at a glance.

Sentry and consent

Event Watcher checks Sentry against the functional consent category, not marketing: it is an error tracker, not an advertising platform.

Many CMP configurations treat error monitoring as strictly necessary and let it run pre-consent; others classify it functional and gate it.

Envelopes firing before any decision show pre-consent status. Whether that is acceptable is policy for your setup.

The sharper compliance angle is payload content: a user.email or a breadcrumb full of query strings is a data-minimization problem no banner fixes, and the raw request view is where you catch it.

Common debugging scenarios

• Errors missing from the Sentry dashboard. Confirm envelopes actually leave the browser and check sentry_key against the expected project DSN. A staging DSN in production is a classic.
• Suspiciously high event volume. Group by Tool and scan the Sentry event count; a render-loop error re-firing every second exhausts quota fast.
• PII in error payloads. Open an envelope's raw body and inspect user, breadcrumbs, and request URLs before the privacy review does.
• Which bundle initialized Sentry? Script Tree shows whether the SDK came from the app bundle, the loader snippet, or an embedded third-party widget shipping its own Sentry.
• Sentry blocked by consent misclassification. If a CMP wrongly buckets Sentry as marketing, denied sessions lose crash reporting. The consent badge on Sentry events confirms what state it fired under.