Sentry: Observability & Monitoring

Sentry is the backbone of Odys' observability strategy, providing real-time error tracking, performance monitoring, and session replay across all execution environments. This setup ensures that issues affecting professionals managing appointments or clients booking sessions are detected and diagnosable quickly—critical for maintaining trust in a service where timing and reliability directly impact real-world interactions.

Overview

Odys leverages Sentry in a multi-layered configuration spanning the Next.js server, edge runtime, and browser. The instrumentation is split across src/instrumentation.ts (server/edge) and src/instrumentation-client.ts (browser), aligning with Next.js' hybrid architecture. Source map uploads are automated via @sentry/nextjs in next.config.ts, ensuring stack traces are deobfuscated in production. A tunnel at /monitoring reroutes browser events to avoid ad-blocker interference, while error boundaries in global-error.tsx guarantee all client-side crashes are captured.

Browser & Edge Instrumentation

The client-side Sentry configuration in src/instrumentation-client.ts enables comprehensive monitoring: error capture, performance tracing (tracesSampleRate: 1), and session replay (replaysSessionSampleRate: 0.1). Replay integration allows visual debugging of user sessions, especially valuable when a client fails to book an appointment or a professional can't load their calendar. The beforeSend filter suppresses known noise like "Object Not Found Matching" errors from browser extensions, reducing false positives.

On the server and edge runtimes, src/instrumentation.ts dynamically imports environment-specific configs, ensuring minimal bundle impact. The onRequestError hook captures all server-side exceptions, while onRouterTransitionStart tracks navigation performance in the client.

Build & Source Map Handling

Source maps are automatically uploaded during build via @sentry/nextjs integration in next.config.ts. The widenClientFileUpload: true option includes more files in the upload, improving stack trace accuracy. This is essential for debugging minified production code, especially in complex flows like Stripe webhook handling or cron-triggered reminders.

The /monitoring tunnel, configured via tunnelRoute, proxies client events through a Next.js rewrite. This bypasses ad-blockers that commonly block *.sentry.io domains, ensuring reliable error ingestion without requiring infrastructure changes.

Design decisions

The split instrumentation model follows Next.js best practices, isolating server/edge logic from browser code. Using @sentry/replayIntegration() selectively samples sessions (10%) to balance insight with cost and privacy. The sendDefaultPii: true setting enables user identification in errors—justified by Odys' professional-user context where support often requires linking issues to specific accounts. The tunnel route trades slight server overhead for guaranteed deliverability, a necessary compromise given the high rate of ad-blocker usage.

Potential improvements

1. Add tracesSampler in client config (src/instrumentation-client.ts): Currently tracesSampleRate: 1 captures 100% of traces in production. Replace with a tracesSampler function to reduce volume based on route or user role, lowering costs without losing critical path visibility.

2. Filter more noise in beforeSend (src/instrumentation-client.ts): Extend the filter to suppress known third-party errors (e.g., from WhatsApp Webhooks or Stripe Elements) by checking event.tags or event.exception.values[0].type, reducing alert fatigue.

3. Centralize DSN and sampling rates in environment variables (src/instrumentation-client.ts): Hardcoded values like replaysSessionSampleRate: 0.1 limit runtime flexibility. Move these to NEXT_PUBLIC_SENTRY_* variables to allow tuning without rebuilds.

References

• src/instrumentation.ts: Server/edge Sentry setup
• src/instrumentation-client.ts: Browser initialization and hooks
• next.config.ts: Source maps, tunnel, and webpack integration
• src/app/global-error.tsx: Client error boundary integration