Next.js blurs the line between frontend and backend, which is exactly why it is so easy to fly blind. A server action, an edge middleware, a route handler, and a client component all ship together, and a slowdown in any of them lands on the same user. Default tooling shows you almost none of it.
Why Does Next.js Need Per-Runtime Monitoring?
The same app runs on the Node runtime, the edge runtime, and the browser. Each fails differently. When we instrumented an edge middleware that threw in a single region, it stayed invisible to our Node-based monitor until we watched it per runtime.
| Runtime | Typical failure | How it's captured |
|---|---|---|
| Node route handlers | A slow database call, 500s | sv.route() wrapping every method |
| Edge middleware | A region-specific throw | Error rate per route from real traffic |
| Browser | Poor LCP or INP | StatvisorAnalytics field data |
How Do You Monitor App Router Handlers?
Wrap your route handlers once and every method reports latency and errors, the same per-route P95 and P99 view explained in P50 vs P95 vs P99. Delivery runs after the response via Next's after(), so it adds no time to the request:
// lib/statvisor.ts
import { Statvisor } from "@statvisor/sdk";
export const sv = new Statvisor({ apiKey: process.env.STATVISOR_API_KEY! });
// app/api/orders/route.ts
import { NextResponse } from "next/server";
import { sv } from "@/lib/statvisor";
export const { GET } = sv.route("/api/orders", {
GET: async () => NextResponse.json({ orders: [] }),
});Track Web Vitals From Real Visitors
Lab scores lie about the visitor on hotel wifi. Drop the analytics component into your root layout to measure LCP, CLS, INP, and TTFB from actual traffic:
// app/layout.tsx
import { StatvisorAnalytics } from "@statvisor/sdk/react";
export default function RootLayout({ children }) {
return (
<html><body>
{children}
<StatvisorAnalytics frontendKey="vl_fe_..." />
</body></html>
);
}
Statvisor tracks App Router handlers and real-user Web Vitals from one key, so a slow TTFB on the edge and a failing LCP in the browser sit on the same timeline.
Close the Remaining Gaps
Instrumentation is step one, but Next.js hides traps a naive setup still misses. Server actions run on the server yet never hit a route handler, so they slip past per-route timing unless you wrap them. Edge middleware can throw in a single region and stay invisible to a Node-based monitor. And a genuinely fast API can still fail Core Web Vitals if the client render is heavy. Close each in turn: start with the four blind spots in Next.js API routes: the monitoring blind spots, connect backend latency to the frontend score in how slow API routes kill your Core Web Vitals, and learn to read the numbers in P50 vs P95 vs P99.
Ready to monitor your API in production?
Statvisor gives you latency percentiles, error rates, and request volume for every route, in minutes, not days.
Get started free →