A static Next.js homepage can stay available while dynamic rendering, a Route Handler, middleware, cache revalidation, or client hydration is failing. Next.js uptime monitoring must sample every rendering and runtime path the application actually uses.
Build a rendering-strategy matrix
Monitor one representative route for each used path:
| Path | What to validate |
|---|---|
| Static output | Current release marker and referenced assets |
| Dynamic server render | User-visible data, status, and server response time |
| Cached or revalidated page | Content freshness and revalidation outcome |
| Route Handler or API route | JSON schema, auth behavior, and dependency access |
| Middleware path | Expected redirect, rewrite, locale, or auth decision |
| Client-rendered feature | Hydration, API call, and critical interaction in a browser |
An HTML keyword cannot prove a Client Component works. Use browser synthetics for login, navigation, forms, and client-side data, and HTTP checks for fast continuous coverage.
Detect stale cache and multi-instance drift
For content that must update, publish a safe canary value or timestamp through the normal data source and measure age until visible. Do not rely on undocumented response headers as a universal contract.
Next.js's official self-hosting guide explains that the server cache is local to each instance by default. Multi-instance deployments need durable shared cache and coordinated invalidation when consistency matters. Probe repeatedly or include a safe instance/release marker to find pods serving different content.
The current cache-handler documentation distinguishes the server cacheHandler used for ISR and route responses from cacheHandlers used by use cache. Monitor the mechanism your application actually configures.
Cover hosting and deployment
- Vercel: check production aliases, Functions, Edge or middleware paths, and application behavior; a successful deployment is not a successful user journey.
- Self-hosted: add Node.js process, reverse proxy, memory, event loop, graceful shutdown, and shared cache health.
- Containers: verify every pod's release and cache behavior after rollout.
- Multi-region: test region-sensitive data, cookies, redirects, and external dependencies.
Run post-deploy checks against the production URL, not only a preview URL. Verify a static route, dynamic route, API route, middleware decision, current asset, and browser interaction before promotion is complete.
Next.js monitoring checklist
- Every used rendering strategy has a representative check
- Route Handler or API response body validated
- Middleware redirects and rewrites tested
- Browser synthetic covers hydration and a key interaction
- Cached content has a measurable freshness contract
- Multi-instance cache and release consistency checked
- Production alias and current assets verified after deploy
- Vercel or self-host runtime metrics correlated with external checks
Continue with the Next.js production monitoring guide, JavaScript SEO monitoring, and API uptime monitoring.
Start monitoring Next.js with external route, JSON content, response-time, domain, and TLS checks.