How do you debug SSR-only issues that don't appear in local development?

A particularly common production-only error is the DYNAMIC_SERVER_USAGE digest. This occurs when you use generateStaticParams on a route that also uses dynamic functions like cookies(), headers(), or searchParams . During build, generateStaticParams runs successfully, so the build passes. But at runtime, when Next.js detects dynamic functions, it throws this error. The fix is either removing generateStaticParams from dynamic routes or ensuring dynamic functions are properly wrapped in Suspense boundaries. Ben S from the Stack Overflow discussion notes that searchParams usage is a frequent culprit for this error .

AWS Amplify has unique characteristics that can cause production-only issues. One developer reported spending 12 hours debugging a Next.js deployment on Amplify . The root cause: Amplify doesn't automatically include environment variables during the build process like Vercel or Netlify do. The solution was manually injecting environment variables into .env.production during the build and adding the __NEXT_PRIVATE_PREBUNDLED_REACT=next flag. Amplify also requires transpiling certain UI library packages and setting output: 'standalone' in next.config.js .

When using custom servers with Next.js (like Firebase Cloud Functions or Express), middleware may work in development but fail in production. This often happens because custom servers need explicit hostname and port configuration for middleware to function correctly . The error Invalid URL: http://undefined:undefined/sw.js appears when Next.js cannot determine the correct hostname. The fix is to provide hostname and port explicitly when initializing Next.js in your custom server .

While you can't attach a debugger to production, you can simulate production behavior locally using next build && next start. For deeper inspection, configure VSCode to debug both server and client code simultaneously . Create launch configurations for Node.js (attaching to Next.js server) and Chrome (attaching to browser). This allows you to set breakpoints in getServerSideProps or Server Components and step through code execution exactly as it would run in production, helping identify timing issues or environment-specific bugs.

For complex production issues, implement OpenTelemetry tracing. Next.js supports experimental OpenTelemetry integration that traces SSR requests . You can instrument your application to capture detailed timing information for database queries, API calls, and component rendering. Tools like Jaeger or Zipkin can visualize these traces, helping identify bottlenecks or failures in production. The Sitefinity documentation provides examples of setting up widget-level tracing with OpenTelemetry, which can be adapted for any Next.js application .