API response times are tracked per route

NIST AU-2 requires that audit-relevant events — including performance events — be captured at sufficient resolution to support analysis. Aggregate server-level response time hides where latency is actually coming from. If your P95 is 800ms but it originates entirely from one /api/reports/export endpoint, aggregate metrics tell you nothing actionable. Per-route latency data is what enables you to write a latency-based SLO ("checkout route P99 < 500ms"), catch regressions in a specific endpoint after a deploy, and prioritize which routes to optimize. This check goes beyond performance-monitoring (any timing data) to require route-level attribution — the difference between knowing "something is slow" and knowing "which endpoint is slow."

Enable Sentry transaction tracing with a non-zero sample rate — Sentry automatically records per-route transaction durations for Next.js.

// sentry.server.config.ts
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 0.1 // 10% of requests — adjust for traffic volume
})

Alternatively, add a custom timing middleware that emits Server-Timing headers:

// middleware.ts
export function middleware(req: NextRequest) {
  const start = performance.now()
  const res = NextResponse.next()
  res.headers.set(
    'Server-Timing',
    `handler;dur=${(performance.now() - start).toFixed(1)}`
  )
  return res
}

The Server-Timing header is consumed by Chrome DevTools in the Network panel and by log platforms that parse response headers, giving you per-route timing with zero external dependencies.