ADR: Observability Consolidation on Dash0

Status: Accepted Date: 2026-01-12 Deciders: Architecture Team Related: OTel Collector Sidecar, OpenTelemetry Semantic Conventions

Context

Current State

The platform currently uses multiple observability tools:

Tool	Usage	Cost Model
Dash0	Backend traces, metrics, logs	Per-GB ingested
Sentry	Frontend errors (miniapp)	Per-event + features
PostHog	Product analytics	Per-event

Problems

1. Fragmented Observability: Cannot correlate frontend errors with backend traces
2. Multiple Vendors: Separate dashboards, alerts, and billing
3. Inconsistent Instrumentation: Different SDKs with different conventions
4. Cost Opacity: Hard to attribute costs across tools

Miniapp Console Logging

The miniapp contains hundreds of console.log statements used for debugging. These:

• Leak into production builds
• Cannot be correlated with backend traces
• Provide no structured data for analysis
• Generate noise in browser developer tools

Decision

1. Consolidate Observability on Dash0

Remove Sentry from miniapp, replace with OpenTelemetry browser SDK sending to Dash0.

Benefits:

• Single pane of glass for all observability
• Correlated traces: frontend click → API call → database query
• Consistent OTEL semantic conventions across stack
• Single vendor relationship and billing

Trade-offs:

• Lose Sentry-specific features (session replay, user feedback widgets)
• OTEL browser SDK less mature than Sentry's SDK
• Migration effort required

2. Separate Session Replay Concern

Session replay is explicitly out of scope for this consolidation.

Rationale:

• Session replay is a distinct concern from observability
• Expensive (per-session pricing)
• Privacy-sensitive (recording user screens)
• Different use case (UX debugging vs system health)

If session replay is needed later:

• PostHog (already installed) has this capability
• Or dedicated tools: LogRocket, FullStory, Clarity
• Keep separate from core observability stack

3. Strip Console Logs in Production

Add Next.js compiler option to remove console statements from production builds:

// next.config.mjs
const nextConfig = {
  compiler: {
    removeConsole: {
      exclude: ['error', 'warn'], // Keep errors visible
    },
  },
};

Benefits:

• Cleaner production output
• Smaller bundle size
• No accidental information leakage
• Errors still captured by OTEL/Sentry during migration

Implementation

Phase 1: Production Console Cleanup (Immediate)

1. Add removeConsole to miniapp's next.config.mjs
2. Verify build succeeds and errors still logged
3. Deploy to staging for validation

Phase 2: OTEL Browser SDK (1-2 weeks)

1. Add @opentelemetry/sdk-trace-web to miniapp
2. Configure OTEL exporter to Dash0 endpoint
3. Instrument key user flows (payments, generation, etc.)
4. Verify traces appear in Dash0

Phase 3: Sentry Removal (After validation)

1. Confirm OTEL capturing equivalent error data
2. Remove @sentry/nextjs package
3. Remove Sentry configuration files
4. Update environment variables

Phase 4: Documentation (Ongoing)

1. Update runbooks to use Dash0 for all debugging
2. Document OTEL instrumentation patterns for frontend
3. Create alerting rules in Dash0 for frontend errors

Consequences

Positive

• Unified Observability: One tool for entire stack
• Trace Correlation: See full request path from browser to database
• Cost Clarity: Single bill, easier to optimize
• OTEL Native: Future-proof, vendor-agnostic instrumentation
• Cleaner Production: No debug logs in browser console

Negative

• Migration Risk: Temporary gap in error visibility during transition
• Learning Curve: Team needs to learn OTEL browser patterns
• Feature Gap: No session replay in Dash0 (mitigated by keeping PostHog option)

Neutral

• PostHog Remains: Keep for product analytics, potential session replay
• Error/Warn Console: Still output for development debugging

Alternatives Considered

1. Consolidate on Sentry

Rejected because:

• Sentry OTEL support is bolted-on, not native
• Backend already standardized on Dash0
• Would require re-instrumenting backend

2. Keep Both Tools

Rejected because:

• Ongoing cost of multiple vendors
• Cannot correlate across tools
• Maintenance burden of multiple SDKs

3. Add Session Replay to Dash0 Migration

Rejected because:

• Session replay is expensive and distinct concern
• Not all users need it
• Can be added separately via PostHog if needed

References

• Dash0 Documentation
• OpenTelemetry Browser SDK
• Next.js Compiler Options
• PostHog Session Replay