Learning Next.js - Observability & Monitoring

#Introduction

An application that's online doesn't stop needing attention. Bugs appear in production, pages slow down for some users, and errors occur on devices you never tested. Without visibility, all of this is only felt when users complain — or leave.

Episode 22 covers observability: monitoring frontend performance and web vitals, error logging with Sentry, real user monitoring and analytics, and production support and incident detection.

#Monitoring Frontend Performance and Web Vitals

#Monitoring Real Metrics

The web vitals from episode 15 need to be monitored on real users, not just on a developer's laptop. Field data differs from lab data: internet speed, device, and user location affect the metrics. Before installing any service, define your key metrics first — error rate, LCP, and request duration are the three most common. Without key metrics, a dashboard is full of data but gives no decisions. Send metrics to an analytics service every time they're measured:

"use client"
 
export function reportWebVitals(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
  })
 
  fetch("/api/web-vitals", {
    method: "POST",
    body,
  })
}

The reportWebVitals(metric) function above sends every measurement to your own route handler. The accumulated data shows performance trends across application versions and device types. Don't forget to monitor external dependencies: third-party API failures often show up as application errors — logging that records upstream status codes helps tell the causes apart. Make sure metric reports can be filtered by version and browser — small differences often signal environment-specific issues.

Start monitoring early, even before a public release. Baselines collected in the preview environment make it easier to detect regressions when new features enter production.

Make sure the metrics collected have a consistent value type across versions — a change in metric data format can break trend comparisons.

#Monitoring Server and Edge

On the server side, monitor TTFB and route execution duration. Deployment platforms provide basic logs and metrics, but for a complete picture, integrate with an observability service like Sentry or OpenTelemetry that tracks performance and errors together. Important metric trends to watch: rising TTFB can signal a database problem or cold start, while rising LCP on mobile devices can signal a bloated bundle. Tie metrics to releases — a dashboard showing performance per version makes it easier to find the cause. Keep logs with a retention period that fits regulations — logs kept too long add cost, too short makes investigation harder.

Also make sure logs contain enough context: request ID, application version, and timestamp. This context becomes the bridge between logs, metrics, and traces during incident investigation.

Apply tiered alerts: a warning level for small degradations worth watching, and a critical level for issues that directly affect users. This hierarchy keeps notifications relevant and doesn't sound the alarm for trivialities. Every alert must have an owner and a short runbook — an alert without an owner is just noise.

#Logging Errors with Sentry

#Setting Up Sentry for Next.js

Sentry is the most popular error tracking platform for JavaScript. Sentry captures errors on the server, client, and edge in a single dashboard — the main reason for its popularity in the Next.js ecosystem. Install its official SDK:```bash icon="iBash" title="Install the Sentry SDK" npm install --save-dev @sentry/nextjs npx @sentry/nextjs@latest wizard@latest -s

 
The command `npx @sentry/nextjs@latest wizard@latest -s{:bash}` configures the project interactively: creating `sentry.server.config.ts` and `sentry.client.config.ts` and injecting the DSN. After that, initialize it in the server configuration:
 
```typescript icon="iTs" title="Initialize Sentry on the server"
import * as Sentry from "@sentry/nextjs"
 
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 1.0,
})

tracesSampleRate: 1.0 records all transactions — in production, lower the value to control cost. The DSN from process.env.SENTRY_DSN is taken from secrets, not committed. Start with a low sampling value, then raise it gradually after validating cost. Sentry can also integrate with the release pipeline: create a new release on deploy, and Sentry links errors to the version and commit that caused them — this speeds up diagnosis from error reports.

#Reading Errors in the Dashboard

Sentry collects errors along with stack traces, user paths, and device context. Its standout features: source maps that map production errors back to TypeScript source code, grouping of similar errors, and automatic alerts when errors spike. This turns an unreadable list of errors into actionable incidents. Also monitor error rate per page: the pages with the most errors are usually the features most in need of a quick fix.

The same error can come from many sources: users, crawlers, and bots. Segmenting errors by source helps distinguish real bugs from automated noise.

#Real User Monitoring and Analytics

#RUM and Product Analytics

Real User Monitoring (RUM) records real user interactions: clicks, navigation, frontend errors, and performance metrics. For product analytics — which pages are viewed most, where users come from, where they drop off — use a service like Plausible, Umami, or Google Analytics. This data answers business questions while identifying pages with performance problems. Start with one or two key metrics instead of installing every service at once, then add tracking gradually — the main pages first, then conversion flows — so data doesn't flood in without direction. For high-volume applications, sampling real user data makes sense: a small fraction of traffic is enough to represent trends without overloading cost. Analytics also helps product prioritization: the most-viewed pages deserve the highest performance attention.

#Respecting Privacy

When using analytics, respect user privacy: offer a consent option for tracking cookies, anonymize IP addresses, and communicate the privacy policy clearly. A privacy-friendly policy also reduces regulatory burden like GDPR when the application is accessed from Europe.

#Production Support and Incident Detection

#Early Detection with Alerts

Observability isn't complete without alerts. Effective rules: send notifications when the error rate rises above a threshold, when web vitals metrics worsen, and when the uptime of critical endpoints drops. Too many alerts numb the team; focus on incidents that affect users.

#Response and Feedback

When an incident is detected: check the dashboards, read the logs, identify the problematic version, then fix and deploy. After the incident, document what happened, how it was detected, and the prevention steps. Every incident is a lesson that makes the next system stronger — and good observability ensures incidents don't drag on. Shape the on-call team to your scale: for small projects, alerts to Slack are enough; for critical services, an on-call rotation with runbooks ensures incidents are handled quickly by the right people.

After an incident is closed, publish a short report to the whole team: timeline, impact, and prevention steps. This transparency builds trust in the process and prevents the same mistake from recurring.

#Closing

Here's what to take away:

• Monitor web vitals from real user data, not just in development.
• Sentry captures errors with context and source maps.
• DSNs and secrets are injected from the environment, not committed.
• RUM and product analytics complete performance and business data.
• Respect user privacy when collecting analytics.
• Alerts focus on incidents that genuinely affect users.

In the next episode, episode 23 — the last episode of this series — we'll discuss stable modern features and future trends: the latest stable App Router features, server components, and streaming, a gradual React Server Components adoption strategy, frontend and fullstack development trends, and strategies to keep your Next.js skills always relevant.