CodersNexus
Lesson 50 of 5024 min read

Next.js Monitoring and Error Tracking with Sentry and Vercel Analytics

Learn how to set up error tracking with Sentry and performance monitoring with Vercel Analytics for a production Next.js application.

Author: CodersNexus

Next.js Monitoring and Error Tracking with Sentry and Vercel Analytics

This module's final lesson addresses a genuinely important question: once your Next.js application is deployed (Lessons 7.3-7.4) through an automated pipeline (Lesson 7.5), how do you actually know if it's working correctly for real users, and find out promptly when it isn't? Testing (Lessons 7.1-7.2) catches problems before deployment, but production monitoring catches problems that only manifest with real user data, real network conditions, and real-world scale — issues no test suite, however thorough, can fully anticipate.

This lesson covers Sentry, a widely-used error tracking service that captures and reports genuine production errors with full context for debugging, and Vercel Analytics, providing real user monitoring for Core Web Vitals (Lesson 6.6) and traffic patterns — together giving you visibility into both correctness (are errors happening?) and performance (is the app actually fast for real visitors?) in production.

Learning Objectives

  • Explain why production monitoring is necessary even with thorough pre-deployment testing.
  • Set up Sentry in a Next.js application for automatic error capturing.
  • Understand what context Sentry captures to make debugging a production error practical.
  • Set up Vercel Analytics for real user Core Web Vitals monitoring.
  • Distinguish between error tracking and performance monitoring as complementary practices.

Core Definitions

  • Error tracking: The practice of automatically capturing, reporting, and providing debugging context for errors that occur in a running production application.
  • Sentry: A widely-used error tracking and application monitoring service, providing automatic error capture, stack traces, and contextual debugging information for JavaScript and many other platforms.
  • Real User Monitoring (RUM): Collecting actual performance data from real visitors' real devices and network conditions, as opposed to synthetic, lab-based testing.
  • Vercel Analytics: A built-in analytics and Core Web Vitals monitoring tool for applications deployed on Vercel, providing real user performance data.
  • Source map: A file mapping minified/compiled production code back to its original source code, essential for making a production error's stack trace actually readable and debuggable.

Detailed Explanation

Even the most thorough pre-deployment testing — comprehensive unit tests (7.1), critical-flow E2E tests (7.2) — cannot fully replicate the sheer variety of real-world production conditions: unusual user input a test suite didn't anticipate, a third-party API unexpectedly returning malformed data, a rare race condition only occurring under real concurrent traffic, or a specific browser/device combination no test environment covered. Production monitoring exists specifically to catch these genuinely unanticipated issues, as they happen, in the real environment where your actual users experience them.

Sentry integrates into a Next.js application (commonly via its official @sentry/nextjs SDK, configured with a short setup wizard) and automatically captures unhandled errors — both on the server (Server Components, Server Actions, Route Handlers throwing unexpectedly) and in the browser (Client Component errors, uncaught JavaScript exceptions) — reporting them to Sentry's dashboard with substantial debugging context: a full stack trace (made readable in production, despite minified code, via automatically uploaded source maps), the specific user affected (if you've configured user identification), the browser and device involved, and a breadcrumb trail of recent actions leading up to the error. This context transforms a vague 'something broke for someone' into an actionable, specific bug report your team can actually investigate and fix, rather than relying on a frustrated user's own incomplete description of what went wrong.

Beyond error tracking, understanding whether your application is genuinely fast for real users — not just in your own testing environment — requires Real User Monitoring (RUM). Vercel Analytics, available for applications deployed on Vercel (Lesson 7.3), automatically collects actual Core Web Vitals data (LCP, INP, CLS, covered in Lesson 6.6) from real visitors' real devices and network conditions, aggregating this into dashboards showing genuine, representative performance across your actual user base — a meaningfully different, more trustworthy signal than a single synthetic test run from a developer's own fast machine and connection, which might not represent what a visitor on a slower device or connection actually experiences.

Together, error tracking and performance monitoring form two complementary halves of genuine production observability: Sentry answers 'is something broken, and for whom, and why?' while Vercel Analytics answers 'is the application genuinely fast for real users, and where specifically is it falling short?' Neither replaces the pre-deployment testing covered earlier in this module — they specifically address the category of issues that testing, by its very nature (working from anticipated scenarios), cannot fully cover: the genuinely unanticipated, only-in-production problems that real-world scale and variety inevitably surface.

Production Monitoring: Error Tracking vs Performance Monitoring

{"heading":"Production Monitoring: Error Tracking vs Performance Monitoring","description":"Visualize the two complementary halves of production monitoring:\n\n[Real user encounters an unexpected error]\n --> Sentry automatically captures: stack trace, browser/device, breadcrumb trail\n --> Team sees an ACTIONABLE bug report in Sentry's dashboard, not just 'something broke'\n\n[Real user loads a page on their actual device/network]\n --> Vercel Analytics automatically records: LCP, INP, CLS for THIS real visit\n --> Aggregated across all real visitors --> dashboard shows genuine, real-world performance\n\nTogether: 'What's broken and why?' (Sentry) + 'Is it actually fast for real users?' (Vercel Analytics)"}

Next.js Practical Example

// sentry.client.config.ts / sentry.server.config.ts — generated by Sentry's setup wizard
import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 1.0, // capture performance data alongside errors
});

// Manually capturing context around a specific operation, for richer debugging
import * as Sentry from '@sentry/nextjs';

export async function processOrder(orderId: string) {
  try {
    await chargeCustomer(orderId);
  } catch (error) {
    Sentry.captureException(error, {
      extra: { orderId }, // this specific order ID appears in the Sentry dashboard
    });
    throw error;
  }
}

// app/layout.tsx — adding Vercel Analytics
import { Analytics } from '@vercel/analytics/react';
import { SpeedInsights } from '@vercel/speed-insights/next';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        {children}
        <Analytics />
        <SpeedInsights /> {/* Real User Monitoring for Core Web Vitals */}
      </body>
    </html>
  );
}

Sentry's configuration files, generated by its official setup wizard, initialize error capturing for both client-side and server-side code with a single, minimal configuration. processOrder demonstrates manually enriching an error report: if chargeCustomer throws, Sentry.captureException explicitly attaches the specific orderId as extra context, meaning when this error appears in Sentry's dashboard, the team immediately knows exactly which order failed, rather than needing to reconstruct that information from a generic error message alone. Adding <Analytics /> and <SpeedInsights /> components to the root layout is the entire setup needed for Vercel Analytics — from that point on, real Core Web Vitals data from actual visitors is automatically collected and available in Vercel's dashboard, requiring no further manual instrumentation for this baseline level of real user monitoring.

How Production Teams Use Monitoring in Practice

  • E-commerce platforms configure Sentry alerts to immediately notify their on-call engineering team via Slack or PagerDuty when a checkout-related error spikes, since even a brief checkout failure directly costs revenue.
  • SaaS companies use Vercel Analytics' real user Core Web Vitals data to identify that a specific page or user segment (e.g., mobile users on slower connections) is experiencing meaningfully worse performance than their own internal testing suggested.
  • Engineering teams use Sentry's breadcrumb trails (a record of recent user actions leading up to an error) to reproduce and fix bugs that would otherwise be extremely difficult to diagnose from a bare stack trace alone.
  • Companies practicing gradual feature rollouts monitor Sentry's error rates closely immediately after each deployment, ready to roll back quickly if a new release introduces an unexpected spike in production errors.
  • Performance-focused teams cross-reference Vercel Analytics' real user data against specific code changes or deployments, helping confirm whether a recent optimization (like those covered in Lesson 6.6) actually improved real-world performance as intended.

Common Mistakes to Avoid

  • Relying solely on pre-deployment testing without any production monitoring, missing genuinely unanticipated issues that only surface with real-world scale and variety.
  • Not configuring source maps correctly, resulting in unreadable, unhelpful stack traces for production errors despite having Sentry set up.
  • Ignoring Sentry alerts or letting error rates climb unnoticed, defeating the entire purpose of having error tracking in place.
  • Relying only on synthetic, single-machine performance testing instead of real user monitoring, missing how the application actually performs for visitors on slower devices or connections.
  • Not attaching meaningful contextual information (like a relevant order ID or user action) to captured errors, leaving the team with a technically-correct but practically unhelpful stack trace alone.

Interview Notes

  • Production monitoring catches genuinely unanticipated issues that pre-deployment testing, working from anticipated scenarios, cannot fully cover.
  • Sentry automatically captures unhandled errors with debugging context: stack traces (via source maps), affected browser/device, and breadcrumb trails.
  • Real User Monitoring (RUM), provided by tools like Vercel Analytics, collects actual performance data from real visitors, distinct from synthetic testing.
  • Source maps are essential for making a production error's stack trace readable despite minified, compiled deployed code.
  • Sentry (error tracking) and Vercel Analytics (performance monitoring) are complementary, covering correctness and performance respectively.

Key Takeaways

  • Production monitoring is the necessary complement to pre-deployment testing, catching the category of issues testing fundamentally cannot anticipate.
  • Sentry's rich debugging context transforms vague production failures into actionable, specific, investigable bug reports.
  • Real User Monitoring provides a genuinely trustworthy performance signal, reflecting actual visitor experience rather than a single synthetic test.
  • This lesson completes the module's full lifecycle: writing code, testing it (7.1-7.2), deploying it (7.3-7.4), automating that process (7.5), and finally observing how it actually behaves in the real world.

Summary

Production monitoring addresses what pre-deployment testing, covered earlier in this module, fundamentally cannot: genuinely unanticipated issues that only surface with real-world scale, variety, and conditions. Sentry, integrated via its official Next.js SDK, automatically captures unhandled errors on both the server and client, providing substantial debugging context — a readable stack trace made possible by automatically uploaded source maps, the affected browser and device, and a breadcrumb trail of recent user actions — transforming a vague production failure into an actionable, specific bug report. Vercel Analytics complements this by providing Real User Monitoring (RUM): actual Core Web Vitals data (LCP, INP, CLS, from Lesson 6.6) collected from real visitors' genuine devices and network conditions, offering a meaningfully more trustworthy performance signal than synthetic, single-machine testing alone. Together, Sentry and Vercel Analytics form two complementary halves of genuine production observability — one answering whether something is broken and why, the other answering whether the application is genuinely fast for real users — completing this module's full lifecycle from writing and testing code through deployment, automation, and finally, real-world observation.