A Next.js app has more failure surfaces than a static site. Here's what to watch.
Next.js monitoring: what to check (pages, API routes, SSR health), why 200 OK isn't enough for SSR, and how to catch render failures.
Next.js apps aren't simple static sites (unless you're using pure static export). Whether you're running SSR, ISR, or server components, a Next.js app has a Node.js process that can crash, hang, or OOM — and a 200 response doesn't guarantee the page rendered correctly. A server component that throws during render can return a 500, but it can also return a 200 with an error boundary's fallback HTML, which looks healthy to a plain HTTP check.
This means Next.js monitoring needs to go beyond status codes. You need keyword checks that verify the expected content is actually in the response body, not just that the server answered. And you need to monitor the API routes separately from the pages, because they fail independently.
Monitor three layers. First, the homepage and 2-3 critical pages with HTTP checks — these catch total process crashes and deployment failures. Second, the same pages with keyword checks for content that must be present (a specific heading, a product name, the logged-in state header) — these catch render failures where the server returns 200 but the page is broken. Third, your API routes (`/api/health`, `/api/auth/session`, and any business-critical endpoints) with HTTP checks — these catch backend failures that don't affect the page server.
If you're using ISR (Incremental Static Regeneration), monitor a page that regenerates on a schedule. An ISR page can serve stale content indefinitely if the revalidation path is broken — the page returns 200, but the content is days old. A keyword check for a timestamp or a "last updated" marker catches this.
The most insidious Next.js failure is a memory leak in a long-running server process. The app works fine for hours, then starts returning 502s or timing out as the Node process hits its memory limit and gets OOM-killed. HTTP monitoring catches the symptom (the 502), but you'll also want to monitor the process itself — either via your hosting platform's metrics (Vercel, Railway, Fly.io all expose this) or via a heartbeat from the server that stops if the process dies.
SurePing's heartbeat monitoring is useful here: have your Next.js app ping a heartbeat URL every minute from a server-side API route or middleware. If the pings stop, the process is hung or dead, even if the HTTP check hasn't caught it yet. Combine this with HTTP and keyword checks on the public-facing pages for full coverage.
SurePing includes this monitor type on every plan — including the free tier.