Frontend framework

Monitor Next.js

Monitor Next.js apps on Vercel, self-hosted, or the edge runtime

HTTPSSLKeywordAPI heartbeatInterval: 30 seconds

Why monitor Next.js

A Next.js deploy passes CI and goes green in Vercel's dashboard, but that's not the same as working. ISR can serve stale content indefinitely when the revalidation job is broken. Edge middleware hitting CPU limits surfaces as intermittent 500s that never show up in development. Custom domains on self-hosted Next.js (Docker on Railway, Fly, a VPS) bring back all the SSL, DNS, and load-balancer failure modes Vercel abstracted away. Monitoring a Next.js app properly means three things: an external HTTP check on the production URL (not localhost, not staging), a keyword assertion on a dynamic field so you catch cache-poisoned "ok" responses, and SSL monitoring on every custom domain. If you run a hybrid setup, with some routes on Vercel and some self-hosted, monitor both environments separately so you can tell where the failure is in the first alert.

Setting up Next.js monitoring

  1. 1
    Expose an /api/health endpoint that returns 200 when dependencies (DB, cache, auth) respond. Use the App Router route handler above or a Pages-Router equivalent.
  2. 2
    Route handlers are dynamic by default in Next.js 15+; keep `export const dynamic = "force-dynamic"` as a safety net so a future opt-in to caching cannot freeze a stale "ok" response.
  3. 3
    Add https://yourapp.com/api/health in Hyperping → New monitor → HTTP, interval 30s.
  4. 4
    Turn on keyword matching for "ok" to catch routes that 200 with an empty body during build failures.
  5. 5
    Add a second SSL monitor on the apex domain. Vercel auto-renews, but custom edge configs can stall.
  6. 6
    Wire alerts to Slack/PagerDuty with a 2-minute confirmation window to absorb Vercel deploy blips.

Example health endpoint

app/api/health/route.ts
import { NextResponse } from 'next/server';

// Route handlers are dynamic by default in Next.js 15+.
// force-dynamic is defensive so a future opt-in to caching cannot freeze a stale response.
export const dynamic = 'force-dynamic';

export async function GET() {
  const checks = {
    db: await pingDatabase(),
    redis: await pingRedis(),
  };

  const healthy = Object.values(checks).every(Boolean);

  return NextResponse.json(
    { status: healthy ? 'ok' : 'degraded', checks, ts: Date.now() },
    { status: healthy ? 200 : 503 }
  );
}

What typically goes wrong with Next.js

ISR revalidation silently failing
Stale pages keep serving with 200s while the revalidation job errors in the background. A keyword monitor on a dynamic field (last-updated timestamp) catches this; a pure HTTP monitor won't.
Middleware edge-runtime CPU limits
Edge middleware on Vercel is limited to 50ms of CPU time on average (net CPU, excluding I/O waits). Heavy JWT verification or geo-lookups silently 500 under load without surfacing in normal logs.
Cold starts on Vercel serverless
First request to a cold function can take several seconds. Vercel fluid compute (default since 2025) makes this rare but not impossible. A 30s-interval monitor keeps the function warm and measures the real user-facing worst case.
Hydration errors breaking interactivity
The page renders but client JS crashes. Pair uptime monitoring with a synthetic check that loads the page in a real browser and asserts a post-hydration element is clickable.

Frequently asked questions

Where should I put the health-check endpoint in a Next.js app?
Use app/api/health/route.ts with the App Router or pages/api/health.ts with the Pages Router. Route handlers are dynamic by default in Next.js 15+; adding `export const dynamic = "force-dynamic"` is a cheap safety net against a future opt-in to caching.
How often should I check a Next.js site?
30 seconds for production. Shorter intervals (10s) increase false positives from deploy blips; longer intervals (1m+) let a broken ISR cache persist for too long.
Does Vercel already monitor my app?
Vercel tracks function errors and deploy status but does not check the URL your users hit. It will not catch DNS misconfigurations, expired SSL on custom domains, stale ISR caches, or middleware silently timing out.
How do I monitor a Next.js app behind authentication?
Create a public /api/health endpoint that does not require auth but verifies auth-dependent services work (e.g., it can reach your auth provider and the DB). Monitor that endpoint, not the protected pages.
Get started

Start monitoring in the next 5 minutes.

Stop letting customers discover your outages first. Set up monitoring, status pages, on-call, and alerts before your next coffee break.

14 days free trial. No card required.