Goal
After Sentry error monitoring is stable, evaluate whether Sentry Performance/Tracing adds useful operational visibility beyond existing Vercel Analytics and production smoke tests.
This is intentionally separate from the baseline rollout so error monitoring can ship without unnecessary telemetry.
Evaluate first
Determine which questions Sentry tracing would answer that the current stack does not, for example:
- slow server rendering/runtime work
- slow route transitions
- third-party/network bottlenecks
- repeated long transactions associated with errors
- performance regressions by release
Compare against existing:
- Vercel Analytics
- Lighthouse/performance budgets
- production smoke tests
- GA/GTM analytics
Do not add duplicate telemetry without a clear operational benefit.
If tracing is justified
Configure conservative sampling.
- Production only or clearly separated production environment.
- Low enough sample rate to control noise/cost.
- Error events should remain captured independently of trace sampling.
- Avoid capturing customer-entered values, URLs with sensitive query strings, headers, cookies, or request bodies.
- Verify CSP changes are minimal.
- Document expected event volume and cost implications.
Identify and name useful transactions/spans only where the framework integration does not already provide sufficient context.
Avoid hand-instrumenting every component.
Session Replay
Do not enable Session Replay as part of this issue by default.
If Replay appears valuable, create a separate owner-decision issue covering:
- consent implications
- masking
- form/input privacy
- cost/storage
- Cookiebot integration
Acceptance criteria
Either:
- tracing is implemented with documented rationale, sampling, privacy safeguards, tests, and production verification,
or:
- the issue documents why existing tooling is sufficient and tracing is intentionally deferred.
No Session Replay is enabled silently.
Goal
After Sentry error monitoring is stable, evaluate whether Sentry Performance/Tracing adds useful operational visibility beyond existing Vercel Analytics and production smoke tests.
This is intentionally separate from the baseline rollout so error monitoring can ship without unnecessary telemetry.
Evaluate first
Determine which questions Sentry tracing would answer that the current stack does not, for example:
Compare against existing:
Do not add duplicate telemetry without a clear operational benefit.
If tracing is justified
Configure conservative sampling.
Identify and name useful transactions/spans only where the framework integration does not already provide sufficient context.
Avoid hand-instrumenting every component.
Session Replay
Do not enable Session Replay as part of this issue by default.
If Replay appears valuable, create a separate owner-decision issue covering:
Acceptance criteria
Either:
or:
No Session Replay is enabled silently.