How to Monitor Next.js API Routes in Production (Step-by-Step)

Your Next.js app is in production. Users are hitting your API routes. But how do you know if /api/users is responding in 200ms or 2000ms? How do you know if your payment webhook is returning 500 errors at 3 AM?

Most developers deploy and hope for the best. In this guide, you'll learn how to set up proper API monitoring for your Next.js routes (with automated health checks, latency tracking, and instant alerts) without adding a heavy APM. (Not sure how to build the health check itself? Start with our Next.js health check guide.)

Why Monitor Next.js API Routes?

Next.js API routes are serverless functions under the hood (on Vercel) or Express-like handlers (on Node). Either way, they can fail silently:

• Cold starts can spike latency from 50ms to 2000ms+
• Database connections can time out without visible errors
• Third-party APIs (Stripe, Auth0, etc.) can degrade and cascade failures
• SSL certificates can expire and break all HTTPS traffic
• DNS changes can propagate incorrectly across regions

Without monitoring, you only find out when users complain, or when revenue drops.

What to Monitor

For each API route, you should track:

Step 1: Add a Health Check Endpoint

Give your monitoring something meaningful to hit. A health route that touches your real dependencies (database, cache) catches far more than a check on your homepage:

// app/api/health/route.ts
import { db } from '@/lib/db'

export async function GET() {
  try {
    await db.query('SELECT 1')
    return Response.json({ status: 'ok' })
  } catch {
    return Response.json({ status: 'error' }, { status: 503 })
  }
}

Return a non-200 status when a dependency fails, so any external checker can detect it without parsing the body.

Step 2: Instrument Your Routes

Create instrumentation.ts in your project root (Next.js 13.4+ supports this hook) and register OpenTelemetry. Every route then produces traces with duration and status, which you can send to the observability backend you already use:

// instrumentation.ts
import { registerOTel } from '@vercel/otel'

export function register() {
  registerOTel({ serviceName: 'my-next-app' })
}

This gives you the internal view: P95 latency and error rates per route, from real traffic.

Step 3: Schedule External Checks and Alerts

Internal metrics can't tell you when the whole app is unreachable. For that you need a check running outside your deployment. Any uptime tool can do it; the plain-code version looks like this:

// check.ts, run every minute from a scheduler outside your app
const url = 'https://your-app.com/api/health'
const start = Date.now()
let status = 0
try {
  const res = await fetch(url, { signal: AbortSignal.timeout(10_000) })
  status = res.status
} catch {}
const ms = Date.now() - start

if (status !== 200 || ms > 2000) {
  await fetch(process.env.SLACK_WEBHOOK_URL!, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: `${url} returned ${status || 'no response'} in ${ms}ms` }),
  })
}

Whatever you use, alert on these conditions:

• API Down: endpoint returns errors or is unreachable
• High Latency: response time exceeds your threshold (e.g., > 2000ms)
• Error Rate: 4xx/5xx percentage exceeds threshold (e.g., > 10%)
• SSL Expiry: certificate expires within N days (e.g., < 14 days)

Send them to a channel someone actually watches (Slack, email, or SMS/pager for critical alerts when you're away from your desk).

Step 4: Deploy and Verify

Deploy your app normally, then break something on purpose (point the health route at a wrong database URL in a preview deployment) and confirm the alert arrives. An alert path you never tested is an alert path you can't trust. Once it works, keep an eye on:

• Response time trends (30-day chart with P95)
• Uptime percentage per endpoint
• Active incidents and their duration
• SSL certificate status and expiry date

Multi-Region Monitoring

One of the biggest advantages of dedicated monitoring is checking from multiple locations, for example:

• North America (e.g. US East)
• South America (e.g. São Paulo)
• Europe (e.g. Paris or Frankfurt)
• Asia Pacific (e.g. Tokyo)

This means you can detect regional outages, like when your Vercel deployment is healthy in the US but timing out from Europe due to a CDN issue.

What About Vercel Analytics?

Vercel provides basic analytics and logging, but it's not a monitoring solution:

• No automated health checks from external regions
• No proactive alerts (you have to check the dashboard manually)
• No P95/P99 latency percentiles per endpoint
• No SSL certificate monitoring
• No incident tracking with duration

Vercel Analytics tells you what happened. Monitoring tells you the moment it happens, and wakes you up if needed.

Can You Do This for Free?

Yes. The health route, OpenTelemetry instrumentation and a scheduled check with Slack webhook alerts cost nothing but a few minutes of setup. Many uptime services also offer free tiers with slower check intervals (often every 5 minutes). Paid plans mainly buy faster intervals, more regions and more alert channels.

Summary

Monitoring your Next.js API routes comes down to three pieces: a health endpoint that touches your real dependencies, instrumentation for per-route P95 latency and error rates, and external checks from several regions that alert you on Slack, email or SMS. Don't wait for users to report outages, know first.

Related Articles

• Next.js middleware guide
• serverless monitoring
• Vercel logs