From vibe code to production-ready: observability for Next.js and Supabase apps

Summary

AI-assisted software development often generates functional code that lacks proper instrumentation, leading to unindexed database queries, N+1 patterns, and fragmented connection strategies. While Supabase provides built-in query analytics, security advisors, and subsystem logs, it cannot trace distributed requests across the entire application stack. Integrating Sentry bridges this visibility gap by establishing distributed traces across Next.js frontends, Deno-based Supabase Edge Functions, and Postgres databases. Teams can forward Supabase logs into dedicated Sentry projects and configure runtime integrations to automatically detect performance bottlenecks such as slow spans and Web Vitals regressions. Furthermore, integrating Model Context Protocol servers allows Sentry's Seer debugger to identify root causes and generate automated fixes for emerging issues.

Context

AI-assisted development tools often generate functional Next.js and Supabase code lacking built-in observability, indexing, or consistent database access patterns. While Supabase provides internal log queries, performance panels, and advisors, it cannot trace requests across the full application stack from frontend actions to database executions.

Approach / What changed

The author recommends instrumenting Next.js applications and Deno-based Supabase Edge Functions with distinct Sentry SDK configurations, alongside draining Supabase logs into a dedicated Sentry project. Integrating Sentry with Supabase and Model Context Protocol servers enables distributed request tracing, automated N+1 query detection, and AI-driven issue root-cause analysis via Seer.

Takeaways

• Supabase logs should be routed via log drains into a separate Sentry project from application code to keep telemetry clean and optimize context for AI analysis tools.
• Configuring Sentry's Supabase integration inside Next.js server configuration turns Supabase SDK calls into named spans with timing data to pinpoint slow database queries.
• Supabase Edge Functions run in Deno and require initializing Sentry's Deno SDK at the top of each function file with full trace sampling.

Related reading

• Sentry · Jun 29, 2026

  Next.js already traces your requests. Here's how to export them with OpenTelemetry.

  Next.js provides out-of-the-box tracing for incoming requests, fetch calls, middleware, and server-side rendering, but traces remain invisible without a configured exporter. Developers can use the @vercel/otel package inside an instrumentation file to initialize the OpenTelemetry SDK and transmit traces to any OTLP-compatible destination. While Next.js automatically creates spans for standard request lifecycles, developers can define custom active spans in the Node runtime to capture specific domain operations and contextual attributes. Exporting traces to backends like Sentry requires configuring standard OTLP endpoint and authentication environment variables. Choosing between direct OTLP export via @vercel/otel and the dedicated Sentry SDK depends on requirements, as direct export lacks browser tracing, error monitoring, and Edge custom spans.

  Kyle Tryon

• Sentry · May 26, 2026

  Your agent can't fix what it can't see