Uptime Monitoring for Next.js and Vercel Apps

Q: How do I monitor ISR revalidation?

Add a page that is revalidated on a known interval and includes a server-rendered timestamp. Monitor the page with keyword or content monitoring that verifies the timestamp changes at the expected cadence. If the timestamp freezes, ISR revalidation has silently broken — typically because the revalidate callback threw or the background fetch is hitting an expired API key.

Q: What causes cold starts in Vercel serverless functions?

Serverless Functions spin down after periods of inactivity and spin up on the next request. The spin-up typically takes 200ms to 2 seconds depending on bundle size, runtime, and region. Heavy dependencies (ORMs, validation libraries) add to cold start time. Monitors on a 1-minute interval keep the function warm as a side effect; Edge runtime functions have near-zero cold starts but a smaller API surface.

Q: Can I monitor Vercel preview deployments?

Yes, via CronAlert's API. Create a monitor programmatically in your CI pipeline after each deploy, point it at the preview URL, and delete it when the PR is merged. This catches production-like issues before they hit main. The CI/CD monitoring guide has the full pattern with GitHub Actions and GitLab CI examples.

Next.js on Vercel is one of the most popular stacks on the web, and it fails in ways that are specific to the platform. Serverless Functions cold-start. ISR revalidation can silently freeze. Edge runtime has a tighter API than Node. Middleware runs on every request and can take the whole app down with one bad condition. Vercel's status page will tell you if Vercel is having a bad day — it will not tell you if your app is broken.

This post is a practical uptime checklist for Next.js apps on Vercel. What to monitor, how to configure each monitor, and the Vercel-specific gotchas that trip teams up.

Why Vercel's status page is not enough

Vercel publishes a status page at vercel-status.com that covers the Vercel platform: deployments, serverless functions, edge network, build pipeline. Almost every outage users actually experience is not a Vercel platform outage. It is:

A bad deploy that compiled successfully but breaks at runtime.
A database connection pool exhausted by a recent traffic spike.
An expired API key to Stripe, Sentry, or a third-party service.
Middleware that now throws on a specific path.
An ISR page that silently stopped revalidating three days ago.
An Edge function hitting its 1MB response size limit.

None of these register with Vercel's platform monitoring. External uptime monitoring is the only way to catch them, and it should run from outside Vercel's own network so platform-wide events don't mask your app-level failures. See the serverless monitoring guide for the broader pattern across Lambda, Cloudflare Workers, and other FaaS platforms.

The five monitors every Next.js app needs

1. The root page

A monitor on / that checks for a 200 status and a known string in the response body. The string should be rendered server-side — a meta title, a navigation link — so the monitor catches SSR failures, not just "the HTML shell loaded."

Interval: 1 minute on paid plans. Keyword: a unique string from the homepage, like your product name or a CTA button label. Unwanted keyword: "Application error" or "This page could not be found".

2. An ISR or SSG page

Incremental Static Regeneration is a common silent-failure mode. The page renders fine — it's serving a stale cached version — but the background revalidation has been broken for hours and nobody notices. Add a rendered timestamp to one ISR page (a small comment is fine, doesn't have to be visible) and monitor that the timestamp is younger than your revalidate interval plus a buffer.

// app/blog/page.tsx
export const revalidate = 300; // 5 minutes

export default async function Page() {
  const posts = await getPosts();
  return (
    <>
      <meta name="x-rendered-at" content={new Date().toISOString()} />
      <main>...</main>
    </>
  );
}

CronAlert can check for x-rendered-at in the response and a content monitor with a regex or freshness check can verify the timestamp is recent. If it freezes, ISR is broken and you get alerted.

3. An API route (Node runtime)

Next.js App Router API routes under app/api/*/route.ts (or Pages Router pages/api/*.ts) run on the Node Serverless Function runtime by default. These are the routes that hit your database, call third-party APIs, and handle form submissions. They fail independently of your static pages.

Pick one read-only API route that exercises your main database and put a monitor on it. Don't pick a write route — the monitor will spam your database with inserts. A GET endpoint that fetches a handful of records is ideal.

4. An Edge runtime route (if you use them)

If you have routes with export const runtime = 'edge', they run on Vercel's Edge network — which is a different runtime with different constraints. They can fail when Node routes are fine, typically because:

The Edge runtime doesn't support a Node API you used (fs, net, child_process).
You exceeded the 1MB response size limit.
You exceeded the 30-second streaming timeout.
A dependency was bundled that uses Node APIs unavailable on Edge.

Monitor at least one Edge route per runtime boundary. Edge failures are fast-fail (no cold start), so a flat 500 from an Edge route is nearly always a real bug, not a transient issue.

5. A dedicated /api/health endpoint

One route whose only job is to answer the question "is everything my app depends on alive?" It should ping the database, ping the cache, verify critical environment variables are set, and return a JSON body with { ok: true } only if all of them succeed.

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

export async function GET() {
  const [dbOk, cacheOk] = await Promise.all([
    db.execute('SELECT 1').then(() => true).catch(() => false),
    redis.ping().then(() => true).catch(() => false),
  ]);
  const ok = dbOk && cacheOk;
  return NextResponse.json({ ok, db: dbOk, cache: cacheOk }, { status: ok ? 200 : 503 });
}

Full pattern, including what not to put in a health endpoint, in the database health endpoint guide.

Vercel-specific gotchas

Cold starts on infrequent routes

Vercel Serverless Functions spin down after periods of inactivity. The next request takes 200ms to 2 seconds longer than a warm request while the function boots. If you have a rarely-hit route that users expect to respond fast, either put a monitor on it (which keeps it warm as a side effect) or move it to the Edge runtime.

A 1-minute CronAlert monitor functions as a keep-warm ping for free. This is a happy side effect of uptime monitoring — if a route is monitored every minute, it stays warm.

Middleware failures are global

Next.js middleware runs on every request that matches its matcher. If your middleware throws for a specific condition — a malformed cookie, a missing header — every request matching that condition gets a 500. This is one of the most common ways a Vercel deploy silently breaks production.

A root page monitor catches this, but only if the monitor itself triggers the broken condition. If the failure is cookie-specific, consider adding a monitor that sets a representative cookie via request headers. The API endpoint monitoring guide covers custom-header monitor configuration.

Environment variables per preview

Vercel's preview deploys get their own set of environment variables, and they are often stale — pointing to a test database that was turned off six months ago, or to a Stripe key that was rotated. A preview monitor that runs against the preview URL catches this before the PR merges.

Set this up in CI: call the CronAlert API after vercel deploy to create a temporary monitor pointed at the preview URL, and delete it after the PR merges. The CI/CD uptime monitoring guide has GitHub Actions and GitLab CI examples.

Function regions and database latency

Vercel runs Serverless Functions in iad1 (US East) by default. If your database is in eu-west, every API route request pays transatlantic latency. This often shows up as intermittent 504 timeouts on complex queries.

Multi-region uptime monitoring doesn't fix the latency problem, but it does surface it — CronAlert logs per-region timing for each check, so you see whether the slow response comes from a specific geographic path. See the multi-region monitoring guide for the probe locations and how to read the data.

The Edge Middleware 1MB limit

Edge Middleware has a 1MB code size limit. If you import a heavy library into middleware — a tree-shaking failure, a bundled copy of Stripe's SDK — your deploy succeeds but middleware fails at runtime with a size error. Check your build output for middleware size on every deploy.

ISR and tag revalidation

revalidateTag and revalidatePath can silently fail when the underlying data fetch throws. Your page keeps serving stale content indefinitely. The rendered-timestamp pattern from monitor #2 above is the only reliable external signal that ISR is actually updating.

Alert configuration for Next.js teams

Route alerts based on severity and ownership:

Root page down: page the on-call. This is a site-wide outage.
/api/health fails: page the on-call. A dependency is down.
Specific API route fails: Slack alert to the team that owns the route. Page on-call if it's the checkout route.
ISR page stale: Slack alert to the content team. Not a page, but needs a fix.
Edge route fails: Slack alert to the platform team.

CronAlert supports per-monitor alert channels, so each monitor can route to the right place without noisy broadcast to a single channel. Use a Slack channel for non-urgent failures and PagerDuty for wake-up-worthy ones. More on this separation in the alert fatigue guide.

Frequently asked questions

What should I monitor in a Next.js app on Vercel?

At minimum: the root page, one ISR page, one API route, one Edge runtime route, and a dedicated /api/health endpoint. These five monitors cover static delivery, ISR revalidation, Node serverless runtime, Edge runtime, and dependency health. Add per-page monitors for revenue-critical routes like checkout, pricing, and login.

Do I need uptime monitoring if Vercel already has one?

Yes. Vercel's status page covers the Vercel platform, not your application. Your app can be down because of a broken API route, a bad deploy, a database outage, an expired API key, or broken middleware — none of which appear on vercel-status.com. External monitoring catches your app's failures regardless of platform health.

How do I monitor ISR revalidation?

Add a server-rendered timestamp to an ISR page and monitor the page's content with a freshness check. If the timestamp stops advancing, ISR revalidation has silently broken. Typical causes: the revalidation fetch throws, an upstream API key expired, or Vercel's build cache is stuck.

What causes cold starts in Vercel serverless functions?

Functions spin down after periods of inactivity and spin up on the next request. The spin-up takes 200ms to 2 seconds depending on bundle size and region. A 1-minute uptime monitor keeps critical routes warm as a side effect. Edge runtime functions have near-zero cold starts but a smaller API surface.

Can I monitor Vercel preview deployments?

Yes, via CronAlert's REST API. Create a monitor in your CI pipeline after each preview deploy, point it at the preview URL, and delete it when the PR merges. See the CI/CD monitoring guide for GitHub Actions and GitLab CI examples.

Get your Next.js app covered

Vercel handles the infrastructure parts of Next.js well. It does not monitor your application's behavior, your dependencies, or the specific routes that matter to your users. That's your job, and five well-placed monitors will catch nearly every failure class Next.js on Vercel is prone to.

Create a free CronAlert account — 25 monitors, 3-minute intervals, API access, and email/Slack/Discord/webhook alerts included. Upgrade to Team for 1-minute intervals and 5-region quorum to catch edge-network and regional routing issues.