How to Monitor a Next.js App in Production

Your Next.js app deploys successfully. Vercel shows a green checkmark. The build log says everything compiled.

Then a customer reports that the pricing page shows stale data, an API route returns 500 errors, and the middleware redirect loop is sending users to a blank page. None of this triggers a platform alert because the app is technically running.

Next.js introduces deployment patterns — server-side rendering, incremental static regeneration, API routes, edge middleware — that create failure modes traditional website monitoring does not catch. A simple ping to your homepage will not tell you whether ISR is revalidating, whether your API routes connect to the database, or whether middleware is executing correctly.

This guide covers what to monitor in a production Next.js app and how to detect the failures that platform dashboards miss.

Why Next.js Monitoring Is Different

Next.js is not a simple static site. Depending on your configuration, a single app can include:

Static pages generated at build time (SSG)
Server-rendered pages generated on each request (SSR)
Incrementally regenerated pages that update in the background (ISR)
API routes that act as serverless backend endpoints
Edge middleware that runs before routing
Client-side code that fetches data after the page loads

Each of these layers can fail independently. Your homepage might be static and always available while your dashboard SSR page crashes because the database connection pool is exhausted. A basic uptime check on / would show 100% uptime while half your app is broken.

What to Monitor

1) Key Pages Across Rendering Strategies

Do not just monitor your homepage. Monitor at least one page from each rendering strategy you use:

Rendering	Example Page	Why It Fails Differently
Static (SSG)	`/`, `/about`	Rarely fails after deploy, but stale content if build breaks
SSR	`/dashboard`, `/account`	Fails on data source errors, slow DB queries, auth issues
ISR	`/blog/[slug]`, `/pricing`	Serves stale content when revalidation fails silently
Client-side	SPA sections	JavaScript errors, API failures, blank screens

For each critical page:

HTTP status check — Verify it returns 200
Content validation — Confirm the page contains expected text, not an error message or fallback
Response time — SSR pages that suddenly take 5 seconds instead of 500ms indicate a backend problem

2) API Routes

Next.js API routes (/api/*) are serverless functions. They share the same failure modes as any serverless deployment:

Timeout — Default is 10 seconds on Vercel. Database queries or external API calls can exceed this.
Cold starts — First invocation after idle time is slower.
Memory limits — Functions that process large payloads can crash silently.
Connection exhaustion — Database connection pools are limited in serverless.

Monitor your critical API routes directly:

GET /api/health — A dedicated health endpoint that tests database connectivity
Your most-used API routes — Payment processing, auth, data fetching
Webhook receivers — If you receive webhooks from Stripe, GitHub, etc.

For each, validate both the status code and the response body. An API route that returns 200 with { "error": "database connection failed" } is not healthy.

3) ISR Revalidation

Incremental Static Regeneration is one of the trickiest parts to monitor. When ISR works, it serves cached pages and updates them in the background. When it fails:

Users see stale content indefinitely
No error is shown — the old cached version keeps being served
The revalidation failure is logged but rarely alerted on

How to detect ISR failures:

Content validation — Check that pages contain expected up-to-date content (e.g., today's date on a page that should update daily)
Cache header monitoring — Check x-nextjs-cache header. Values: HIT (cached), STALE (serving cached while revalidating), MISS (generating fresh). Persistent STALE may indicate revalidation failures.
Monitor the data source — If ISR pulls from a CMS or database, monitor that source directly

4) Edge Middleware

Next.js middleware runs before every matched request. A broken middleware can:

Create redirect loops
Block all traffic with an error
Add latency to every request
Fail silently and pass through without executing its intended logic

Monitor middleware behavior by:

Checking redirects work — If middleware handles auth redirects, verify the redirect chain completes
Testing protected routes — Verify that unauthenticated requests are correctly redirected
Response time on middleware-heavy paths — A sudden increase may indicate middleware errors or retry loops

5) Environment Variables and Configuration

A common Next.js deployment failure: environment variables that exist locally or in staging but are missing in production. This causes:

API routes that cannot connect to databases
Auth providers that fail silently
Third-party integrations that return errors
Pages that render but with missing functionality

After every deployment, verify that key pages and API routes function correctly with a post-deploy smoke test.

Vercel-Specific Monitoring

If you deploy on Vercel, the platform provides some built-in monitoring. But it has gaps:

Vercel Provides	What It Misses
Build status (success/fail)	Runtime errors after successful build
Function invocation counts	Whether functions return correct data
Edge network status	Your specific middleware behavior
General platform uptime	Your app's page-level availability
Deployment logs	ISR revalidation failures

Vercel monitors its platform. You need to monitor your application on that platform.

Monitoring self-hosted Next.js

If you self-host Next.js (Docker, Node.js server, PM2), you also need:

Process monitoring — Is the Node.js process running?
Port check — Is the server accepting connections on the expected port?
Memory and CPU — Next.js SSR can be memory-intensive under load
Health endpoint — A /api/health route that checks database connectivity and returns status

Common Next.js Failure Modes

Failure	Symptom	Detection
SSR data source down	500 error or timeout on dynamic pages	HTTP check + status code validation
ISR revalidation failing	Stale content, no visible error	Content validation on ISR pages
API route timeout	504 Gateway Timeout	HTTP check on API routes
Middleware redirect loop	Browser shows "too many redirects"	HTTP check detects redirect loop
Missing env variable in production	Partial functionality, broken integrations	Post-deploy API route checks
Database connection pool exhausted	Intermittent 500 errors on SSR/API	Frequent checks catch intermittent failures
Build cache corruption	Pages serve outdated code	Content validation after deploy
Edge function cold start	Slow first response after idle	Response time monitoring with threshold alerts
Client-side JS bundle error	Blank page or non-functional UI	Content validation (check for expected DOM elements)
CDN cache serving error page	Cached 500 response served to all users	HTTP check from multiple regions

Practical Monitoring Setup

Minimum for every Next.js app

HTTP check on homepage — 1-minute interval, verify 200 status
HTTP check on one SSR page — Catch server-rendering failures
HTTP check on primary API route — Validate status and response body
SSL certificate monitoring — Catch renewal failures
Response time alert — Detect performance regressions after deploys

Comprehensive setup for production apps

All of the above, plus:
Content validation on ISR pages — Verify content freshness
HTTP checks on all critical API routes — Auth, payments, data endpoints
Multi-region checks — Verify the app works globally, not just from one region
Post-deploy validation — Automated checks triggered after each Vercel deployment
Heartbeat monitoring — For cron jobs and background tasks using Next.js API routes
DNS monitoring — Catch domain configuration issues

Post-deploy monitoring with webhooks

Trigger monitoring checks after every deployment:

# In your deploy pipeline or Vercel deploy hook
curl -X POST https://web-alert.io/api/trigger-check \
  -H "Authorization: Bearer $WEBALERT_TOKEN"

This validates that the newly deployed version actually works, closing the gap between "deploy succeeded" and "app works."

How Webalert Helps

Webalert monitors your Next.js app the way users experience it:

60-second checks from global regions — detect failures in under 2 minutes
Content validation — verify pages contain expected content, not stale ISR data
API route monitoring — check status codes and response bodies on /api/* endpoints
SSL monitoring — catch certificate issues before browsers block your site
Response time tracking — detect SSR performance regressions
Multi-region checks — verify your app works globally, not just from your deploy region
Heartbeat monitoring — track cron jobs and background tasks
Multi-channel alerts — Email, SMS, Slack, Discord, Teams, webhooks

See features and pricing for details.

Summary

Next.js apps have multiple rendering strategies, each with distinct failure modes.
Monitor at least one page per rendering strategy (SSG, SSR, ISR, client-side).
API routes are serverless functions — monitor them for timeouts, errors, and correct responses.
ISR failures are silent. Use content validation to catch stale data.
Platform dashboards (Vercel, Netlify) monitor their infrastructure, not your application.
Start with homepage, one SSR page, one API route, SSL, and response time monitoring.
Add content validation and post-deploy checks as your app grows.

Your framework handles rendering. Monitoring proves it is working.

Monitor your Next.js app from the user's perspective

Start monitoring with Webalert →

See features and pricing. No credit card required.