Sentry performance monitoring
Sentry is an error-monitoring and performance platform that captures exceptions and, through tracing, transaction timings across front-end and backend. Its browser SDK reports errors and performance from real sessions. This page describes its observability data model and privacy posture even-handedly, distinct from web analytics, with no ranking.
What this means
Sentry began as error monitoring — capturing unhandled exceptions with stack traces, breadcrumbs, and context so developers can reproduce and fix them — and added performance monitoring via distributed tracing. The browser SDK reports both errors and performance from real user sessions.
Its purpose is reliability and diagnosis, not audience measurement: it tells you what broke or what was slow and why, rather than how many people visited.
Data model and posture
The core records are error events (with stack traces and breadcrumbs) and performance transactions composed of spans. Tracing can link a browser transaction to backend spans, giving an end-to-end view of a slow or failing interaction.
Because captured context can include request data and breadcrumbs, Sentry provides data-scrubbing and sampling controls. The privacy posture depends on those settings — scrubbing sensitive fields and sampling reduce the surface, fuller capture increases it.
- Error events with stack traces and breadcrumbs
- Performance transactions built from tracing spans
- Links browser and backend in one trace
- Scrubbing and sampling govern what is sent
How it appears in analytics and logs
Sentry in a page means an SDK is capturing exceptions and performance spans. A spike here signals broken or slow code paths, not a marketing-analytics measurement issue.
Diagnostic use case
Use Sentry to catch and diagnose errors and slow transactions in browsers and services, correlating a failing user action with the stack trace and span that caused it.
What WebmasterID can help detect
WebmasterID's website observability covers traffic and bots; an error/performance tool like Sentry is the complementary reliability lens on the same sessions.
Common mistakes
- Reading error or transaction counts as visitor metrics.
- Capturing context without scrubbing sensitive fields.
- Ignoring sampling when interpreting absolute volumes.
Privacy and accuracy notes
Error and tracing data can include context such as request details and breadcrumbs, so scrubbing and sampling settings govern what is sent. This is educational, not legal advice.
Related pages
- Datadog Real User Monitoring
Datadog Real User Monitoring (RUM) is an observability product that captures performance timings, errors, resource loads, and user-session data from real browsers and mobile apps. It is oriented toward front-end performance and reliability rather than marketing analytics. This page describes its data model and privacy posture even-handedly.
- New Relic Browser monitoring
New Relic Browser is the front-end monitoring component of the New Relic observability platform, capturing real-user page timings, errors, and AJAX/resource performance, and correlating them with backend telemetry. This page describes its observability data model and privacy posture even-handedly, distinct from web analytics, with no ranking.
- The exception event (error tracking)
An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.
- Website observability
Traffic and bot lens alongside error monitoring.
Sources and verification notes
- Sentry — DocumentationVendor docs for error monitoring and performance tracing.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.