Monitoring a Next.js Application in Production: What Actually Matters

Your Next.js application is deployed and serving real users. Congratulations. Now the harder part: knowing when something goes wrong before your users tell you (or before they silently leave).

I have monitored Next.js applications at various scales — from side projects with 100 daily users to production apps with tens of thousands. Here is what I have learned about monitoring that actually matters versus monitoring that creates noise without value.

The Monitoring Hierarchy

Not all monitoring is equal. In order of importance:

Is the application available? (Can users reach it at all?)

Is the application functional? (Does it actually work — can users complete tasks?)

Is the application performant? (Is it fast enough that users are not frustrated?)

Is the application healthy? (Are resources within acceptable bounds?)

Most developers start with #4 (CPU metrics, memory usage) and never set up #1 and #2 properly. Invert this. A user does not care about your CPU usage. They care whether the page loads and whether their action succeeds.

Layer 1: Availability Monitoring

The simplest and most important monitoring. Is your application responding?

External uptime monitoring: a service that hits your application from outside your infrastructure every 30-60 seconds. If it fails: alert immediately. Tools: UptimeRobot (free tier sufficient for small apps), Better Uptime, Pingdom. Configure: check your homepage AND a critical API endpoint (sometimes the frontend serves but the API is down).

Health check endpoint: create /api/health that verifies: the application can respond, the database is reachable, and critical external services are accessible. Return 200 for healthy, 503 for degraded.

For Next.js specifically: middleware can silently fail without the application appearing down. Your health check should exercise a code path that goes through middleware.

Layer 2: Error Monitoring

You need to know when errors happen — before users report them (if they ever do — most just leave).

Client-side errors: JavaScript errors in the browser. Unhandled promise rejections. React error boundaries triggered. A user sees a blank screen or broken interaction. You need: Sentry, Bugsnag, or similar error tracking. Configure the Next.js SDK — it captures errors in both client components and server-side rendering.

Server-side errors: API route failures. Server Component rendering errors. Middleware crashes. These are invisible to client-side monitoring. Sentry's Next.js integration captures both sides.

What to alert on: new error types (first occurrence of an error you have never seen), error rate spikes (sudden increase in known errors — regression), and critical path errors (errors in checkout, authentication, or core user flows — always alert).

What NOT to alert on: individual occurrences of non-critical errors (log them, review weekly). Network timeouts from bad connections (user-side issue, not yours). Bot traffic generating 404s (noise, not signal).

Layer 3: Performance Monitoring

Slow is the new down. A page that takes 8 seconds to load is functionally broken even though it technically works.

Core Web Vitals: LCP (Largest Contentful Paint), FID/INP (interactivity), CLS (layout stability). Monitor real user metrics, not synthetic benchmarks. Real users have slower devices and network connections than your development machine.

For Next.js: Vercel Analytics provides Core Web Vitals tracking automatically if you deploy on Vercel. Alternatively: use @next/third-parties or configure a RUM (Real User Monitoring) solution.

API response times: track p50, p95, and p99 response times for critical API routes. P50 tells you the typical experience. P99 tells you the worst 1% experience. If p99 degrades significantly: investigate (usually a database query that occasionally locks or an external service that intermittently slows).

Server Component rendering time: in Next.js App Router, Server Components render on every request (unless cached). If rendering is slow: users see a loading state longer. Monitor server response time (Time to First Byte) as a proxy.

Layer 4: Infrastructure Monitoring

The traditional metrics: CPU, memory, disk, network. Important but less directly actionable for application developers.

What to watch: memory usage trending upward over time (memory leak — common in Node.js with event listeners or cache growth), disk usage approaching limits (logs growing, database file expanding for SQLite), and database connection pool exhaustion (more requests than available connections).

For serverless deployments (Vercel, Netlify): you get limited infrastructure metrics. Cold start times and function duration matter more than CPU. Monitor function execution time and identify cold-start-heavy routes.

Setting Up Sentry for Next.js

Sentry is the de facto error monitoring for Next.js. Setup:

Install the SDK: @sentry/nextjs. Run the setup wizard: npx @sentry/wizard@latest -i nextjs. Configure: DSN, environment, release tracking, source maps upload.

Critical configuration: set tracesSampleRate based on traffic (0.1 for high-traffic apps, 1.0 for low-traffic). Enable session replay for debugging complex user issues. Configure beforeSend to filter noise (bot errors, extension-caused errors, network timeouts).

Organize alerts: assign error ownership by code area. Frontend errors go to frontend team channel. API errors go to backend team. Unassigned errors go to on-call.

Alerting Without Alert Fatigue

The biggest monitoring mistake: too many alerts. When everything alerts: nothing alerts (you ignore them all).

Rules: alert only on actionable issues (if you cannot do anything about it at 2am — do not page for it), group related errors (one alert for "authentication is broken" not 500 individual error alerts), set thresholds not absolutes (alert on "error rate increased 3x" not "any error occurred"), and have clear escalation (warning → alert → page, with increasing severity).

My setup: Slack channel for warnings (review daily), PagerDuty for critical issues (immediate response required), weekly error review (address accumulated non-critical issues). This keeps alert volume to 2-3 per week (actionable) instead of 50 per day (noise).

Monitoring Specific to Next.js

Build output size: monitor bundle size per route. Next.js provides build output analysis. If a route's JavaScript bundle grows unexpectedly: investigate (accidental dependency inclusion, missing code splitting).

ISR revalidation: if using Incremental Static Regeneration — monitor revalidation failures. A silently failing revalidation means users see stale content indefinitely.

Middleware execution: middleware runs on every request in Next.js. If middleware becomes slow or errors: it affects the entire application. Monitor middleware specifically.

Edge function cold starts: if deploying middleware or API routes to edge functions — cold start latency varies by provider. Monitor p95 response times to catch cold-start degradation.

What I Monitor for AIDToolStack

For context — our actual monitoring setup for a Next.js application with moderate traffic:

Uptime: external ping every 60 seconds (UptimeRobot free tier). Alerts via Slack and email if down for 2 minutes.

Errors: Sentry with source maps. Client and server errors captured. Alert on new error types and error rate spikes. Weekly review of accumulated issues.

Performance: Core Web Vitals via analytics. Monthly review of performance trends. Alert if LCP p75 exceeds 2.5s.

Database: connection pool monitoring. Query duration tracking for slow queries (>500ms). Alert on connection pool exhaustion.

Infrastructure: memory and CPU via hosting platform metrics. Alert on sustained high memory (potential leak).

Total monitoring cost: approximately 20 dollars per month (Sentry free tier plus UptimeRobot free tier plus hosting platform included metrics). Not expensive. The cost of NOT monitoring — silent failures losing users — is far higher.

The Philosophy

Monitor the user experience first. Infrastructure second. Alert sparingly. Review regularly. The goal is: sleep well knowing that if something genuinely breaks, you will know immediately. And for everything that is not an emergency: review it on your schedule, not at 2am.

Production monitoring is not about catching every anomaly. It is about catching the anomalies that matter — the ones that affect real users completing real tasks. Everything else is noise.