DEV Community

Vigilmon
Vigilmon

Posted on

How to Monitor Your Next.js App with Vigilmon (SSR, API Routes, Edge Functions)

Next.js is the most popular React framework for production apps. It runs server-side rendering, API routes, edge functions, and static pages — and each of those layers can fail independently.

This guide shows how to add external uptime monitoring to your Next.js app with Vigilmon, covering all the layers that matter: SSR pages, API routes, and edge deployments.

Why Next.js Apps Need External Monitoring

Next.js apps have more failure modes than static sites:

  • SSR pages can fail if your data fetching fails at request time
  • API routes can crash independently from your frontend
  • Edge functions run on different infrastructure than your Node.js server
  • Static pages can have stale CDN caches that serve 200s while your origin is down

An uptime monitor that only checks your homepage misses all of this.

Step 1: Add a Health API Route

Create app/api/health/route.ts (App Router):

import { NextResponse } from "next/server";

export async function GET() {
  const checks: Record<string, string> = {};

  // Check database connection
  try {
    await prisma.$queryRaw`SELECT 1`;
    checks.database = "ok";
  } catch (error) {
    checks.database = "error";
  }

  const isHealthy = Object.values(checks).every(v => v === "ok");

  return NextResponse.json(
    { status: isHealthy ? "ok" : "degraded", checks },
    { status: isHealthy ? 200 : 503 }
  );
}
Enter fullscreen mode Exit fullscreen mode

For Pages Router, create pages/api/health.ts:

import type { NextApiRequest, NextApiResponse } from "next";

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  return res.status(200).json({ status: "ok" });
}
Enter fullscreen mode Exit fullscreen mode

Step 2: Verify SSR Data Fetching Works

Your health route tests the API layer. But SSR pages can fail independently. Add an error boundary and structured logging so failures surface quickly.

For getServerSideProps, wrap data fetching to return a 500 status on failure:

export async function getServerSideProps(context) {
  try {
    const data = await fetchDashboardData();
    return { props: { data } };
  } catch (error) {
    console.error("SSR data fetch failed:", error);
    return { notFound: true }; // or redirect to an error page
  }
}
Enter fullscreen mode Exit fullscreen mode

Step 3: Set Up Vigilmon Monitoring

  1. Sign up at vigilmon.online — free for 50 monitors, 1-minute checks.

  2. Add monitors for each layer:

Monitor URL Alert On
Homepage (SSR) https://yourapp.com/ Non-200, timeout
API Health https://yourapp.com/api/health Non-200
Core API route https://yourapp.com/api/users Non-200
  1. Set alerts to Slack and email. Configure "confirm after 1 failure" for production.

Monitoring Edge Functions (Vercel/Cloudflare)

If you deploy Next.js edge functions, add a dedicated edge health check:

// app/api/health/edge/route.ts
export const runtime = "edge";

export async function GET() {
  return new Response(JSON.stringify({ status: "ok", runtime: "edge" }), {
    headers: { "Content-Type": "application/json" },
  });
}
Enter fullscreen mode Exit fullscreen mode

Monitor this separately in Vigilmon — edge function failures are invisible to your main server health check.

Monitoring Multiple Environments

Next.js apps typically have preview deployments, staging, and production. Add a monitor for each:

  • Production: https://yourapp.com/api/health — alert on 1 failure
  • Staging: https://staging.yourapp.com/api/health — alert on 3 failures
  • Preview: optional, useful for catching regressions before merge

Setting Up Incident Alerts

When Vigilmon detects a failure:

  1. First alert fires after 1 check fails (configurable)
  2. Subsequent alerts repeat on a schedule until resolved
  3. Recovery alert fires when the endpoint comes back

Connect Vigilmon to your team Slack channel so incidents are visible to everyone on call, not just whoever happened to check their email.

Common Next.js Outage Patterns

After monitoring many Next.js deployments, these are the common failure modes:

  1. Cold start timeouts — serverless functions take too long to initialize; externally this looks like a 504
  2. Data fetching timeouts in SSR — getServerSideProps waits too long for a slow database
  3. Memory leaks in API routes — accumulate over time, eventually OOM kills the process
  4. Build/deploy race conditions — new deployment incomplete while traffic is routed to it
  5. Edge and Node runtime conflicts — using a Node.js-only library in an edge route

External monitoring from Vigilmon sees exactly what your users see during all of these.

Start monitoring your Next.js app free at vigilmon.online

Top comments (0)