Monitoring and Debugging in Production

// Server errors are redacted in production: the client sees a
// generic message and a digest, and the full stack is in your logs
// under that digest. Show the digest, or the user has nothing to
// quote to support.
export default function Error({ error }) {
  return <p>Something went wrong. Reference: {error.digest}</p>
}

// Capture both sides. Sentry's Next SDK wires server components,
// actions, route handlers and the browser:
// instrumentation.ts
export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') await import('./sentry.server.config')
  if (process.env.NEXT_RUNTIME === 'edge')   await import('./sentry.edge.config')
}
export const onRequestError = Sentry.captureRequestError

// What client-side capture catches that server logs never will:
//   hydration mismatches
//   chunk load failures after a deploy
//   errors in event handlers, which no boundary catches
//   failures on browsers you do not test

// A global handler for unhandled rejections, so they are at least
// counted:
window.addEventListener('unhandledrejection', (e) => report(e.reason))

// middleware.ts — generate once, at the edge of the system
const id = req.headers.get('x-request-id') ?? crypto.randomUUID()
const headers = new Headers(req.headers)
headers.set('x-request-id', id)
const res = NextResponse.next({ request: { headers } })
res.headers.set('x-request-id', id)        // back to the client too

// Read it anywhere on the server
const requestId = (await headers()).get('x-request-id')

// Log structured objects, not strings — a serverless log sink cannot
// grep a sentence usefully:
console.log(JSON.stringify({
  level: 'info', event: 'problem_published',
  requestId, userId: user.id, slug, ms: Date.now() - started,
}))

// Forward it to your backend so both systems share one identifier
// (see the Full-Stack Integration track — this is the same id).
headers: { 'x-request-id': requestId, cookie: cookies().toString() }

// Never log: request bodies of auth or payment endpoints, tokens,
// full cookie headers, or personal data you would not put in an email.

// Vercel keeps runtime logs for a limited window on lower plans, so
// drain them somewhere durable if you need history.

// Framework-specific:
//   the static/dynamic mix in the build output — a route flipping to
//     dynamic raises cost and latency silently
//   function duration and invocation count per route
//   cold start frequency
//   ISR cache hit rate, if you self-host
//   image transformation count, if you pay per transform

// Application:
//   error rate by route, not just overall
//   p95 and p99 latency, never the average
//   Core Web Vitals from the field
//   one business metric — signups, submissions — because "no errors
//     but nobody can check out" is a real and silent failure

// Alert on the SHAPE of failures:
//   a spike in 401s      -> auth broke, or a token change shipped
//   a spike in 422s      -> the frontend started sending something new
//   a spike in 404s      -> a broken link or a bad deploy
//   a spike in timeouts  -> an upstream dependency is degrading

// And the local reproduction rule that saves the most time:
npm run build && npm start
// The dev server does not cache, does not prerender, and double-
// renders. Anything about caching, staleness or a production-only
// error must be reproduced against a real build first.