Skip to content
Homeβ€Ί JavaScriptβ€Ί Advanced Error Handling & Logging in Next.js 16 Applications

Advanced Error Handling & Logging in Next.js 16 Applications

Where developers are forged. Β· Structured learning Β· Free forever.
πŸ“ Part of: React.js β†’ Topic 41 of 47
Production-grade error handling, monitoring, logging, and user feedback systems in Next.
πŸ”₯ Advanced β€” solid JavaScript foundation required
In this tutorial, you'll learn
Production-grade error handling, monitoring, logging, and user feedback systems in Next.
  • Next.js 16 error boundaries are route-segment-scoped β€” each error.tsx catches its segment and children
  • global-error.tsx is mandatory β€” without it, root crashes render blank white pages
  • Structured logging with correlation IDs is the foundation of production observability
✦ Plain-English analogy ✦ Real code with output ✦ Interview questions
⚑Quick Answer
  • Next.js 16 provides error.tsx, global-error.tsx, and notFound() for hierarchical error boundaries
  • Structured logging with correlation IDs enables tracing errors across server/client boundaries
  • Sentry or similar APM tools capture unhandled exceptions with full stack traces and breadcrumbs
  • Rate-limit error reporting to avoid overwhelming monitoring services during cascading failures
  • Custom error classes with error codes enable consistent user-facing messages without leaking internals
  • Production insight: silent errors in Server Components kill observability β€” always log before swallowing
🚨 START HERE
Next.js 16 Error Quick Debug Commands
Immediate diagnostic commands for production error triage
🟑Server Component renders empty without error
Immediate ActionCheck server logs for unhandled promise rejections
Commands
kubectl logs -l app=nextjs --tail=200 | grep -i 'unhandled\|error\|reject'
next dev --inspect
Fix NowAdd process.on('unhandledRejection', handler) in instrumentation.ts
🟑Client-side error boundary not firing
Immediate ActionVerify error.tsx is in the correct route segment directory
Commands
find app -name 'error.tsx' -o -name 'global-error.tsx'
next build 2>&1 | grep -i 'error\|boundary'
Fix NowEnsure error.tsx is a Client Component with 'use client' directive
🟑Logging service receiving no error events in production
Immediate ActionTest Sentry DSN connectivity from production environment
Commands
curl -X POST https://sentry.io/api/[PROJECT_ID]/envelope/ -H 'X-Sentry-Auth: Sentry sentry_key=[KEY]' -d '{}'
NEXT_PUBLIC_SENTRY_DSN=https://... node -e "console.log(process.env.NEXT_PUBLIC_SENTRY_DSN)"
Fix NowVerify SENTRY_DSN is set in production environment, not just .env.local
🟑Error logs missing request context and user ID
Immediate ActionImplement correlation ID middleware before all routes
Commands
grep -r 'correlationId\|x-request-id' middleware.ts
curl -I http://localhost:3000/api/test | grep x-request-id
Fix NowAdd X-Request-ID header generation in middleware.ts and pass via headers()
Production IncidentSilent Server Component Failures Black-Holing 23% of Dashboard RequestsA fintech startup discovered that 23% of their dashboard page loads returned empty data sections with no error indication to users or monitoring systems.
SymptomUsers reported blank data panels on the dashboard. No error appeared in Sentry. No 5xx responses in server logs. Client-side metrics showed successful 200 responses with zero-length data arrays.
AssumptionThe team assumed the upstream API was intermittently returning empty responses. They spent two weeks optimizing API retry logic.
Root causeA Server Component was silently catching a Prisma connection pool timeout error inside an inline try/catch. The catch block returned an empty array instead of throwing or logging. The error boundary never triggered because no exception propagated. The connection pool exhaustion was caused by a missing connection release in a background job.
FixRemoved inline try/catch from Server Components. Let errors propagate to the nearest error.tsx boundary. Added structured logging with correlation IDs in every data-fetching layer. Implemented connection pool monitoring with alerting at 80% utilization.
Key Lesson
Never swallow errors silently in Server Components β€” log them and let boundaries handle fallback UIConnection pool exhaustion is a slow-building failure β€” monitor utilization trends, not just current stateEmpty data responses are often masked errors, not legitimate empty results β€” validate with source-of-truth queries
Production Debug GuideSymptom to resolution path for Next.js 16 error scenarios
User sees blank white page with no error message→Check global-error.tsx — if missing, Next.js renders unstyled fallback. Add it to app/ root immediately.
Error boundary catches but shows stale/frozen data→Call reset() from error.tsx props to reset the boundary. Ensure error state does not cache previous successful response.
Server Component error not appearing in monitoring→Verify logging runs before any try/catch. Use console.error with structured JSON — plain console.error loses context in production log aggregation.
Server Action error returns generic 500 to client→Return structured error objects from Server Actions using { error: { code, message } } pattern. Never throw raw Error objects to the client.
Error only occurs in production, not in development→Check NODE_ENV-dependent code paths. Run next build && next start locally. Verify environment variables match production — missing env vars cause silent failures.

Next.js 16 introduces refined error boundary semantics with improved streaming support and Server Component error propagation. Understanding how errors flow through the rendering pipeline is critical for production reliability.

Most teams bolt on error handling after launch. By then, silent failures have already corrupted user trust and debugging costs 10x more. The architecture below prevents that.

Common misconception: wrapping everything in try/catch is sufficient. It is not β€” Next.js has distinct error surfaces for Server Components, Route Handlers, Server Actions, and Client Components, each requiring different instrumentation.

Next.js 16 Error Boundary Hierarchy

Next.js 16 uses a nested error boundary system that maps to your route segment structure. Each route segment can define its own error.tsx, which catches errors from all children β€” Server Components, Client Components, and data fetching within that segment.

The global-error.tsx file at the app/ root catches errors that escape all nested boundaries. It must be a Client Component and defines the entire application's last-resort fallback.

Errors in Server Components propagate differently than Client Component errors. Server Component errors bubble up through the React Server Components tree to the nearest error.tsx. Client Component errors follow the standard React error boundary rules.

Streaming responses complicate this further. If a Server Component error occurs after the initial HTML shell has streamed, the error boundary renders a fallback within the already-partially-rendered page β€” not a full page replacement.

app/dashboard/error.tsx Β· TSX
123456789101112131415161718192021222324252627282930
'use client'

import { useEffect } from 'react'
import { io } from '@thecodeforge/monitoring-client'

interface ErrorBoundaryProps {
  error: Error & { digest?: string }
  reset: () => void
}

export default function DashboardError({
  error,
  reset
}: ErrorBoundaryProps) {
  useEffect(() => {
    // Log to monitoring with route context
    io.thecodeforge.monitoring.captureException(error, {
      tags: { route: '/dashboard', boundary: 'segment' },
      extra: { digest: error.digest }
    })
  }, [error])

  return (
    <div className="error-boundary">
      <h2>Dashboard unavailable</h2>
      <p>We encountered an issue loading your dashboard data.</p>
      <button onClick={reset}>Retry</button>
    </div>
  )
}
Mental Model
Error Boundary Nesting Model
Think of error boundaries as firebreaks in a forest β€” each one contains damage to its section, preventing a single tree fire from burning the entire forest.
  • Route segment error.tsx catches errors from that segment and all children
  • global-error.tsx catches errors that escape all nested boundaries β€” it replaces the entire layout
  • Layout error boundaries persist across navigation β€” page boundaries reset on route change
  • Server Component errors bubble to the nearest parent error.tsx in the RSC tree
  • Client Component errors follow React's standard class-component boundary rules
πŸ“Š Production Insight
Missing global-error.tsx means a root-level crash renders a blank white page with no recovery option.
Users see nothing β€” no error message, no retry button, no guidance.
Rule: always ship global-error.tsx as a Client Component with a retry mechanism and monitoring hook.
🎯 Key Takeaway
Error boundaries are route-segment-scoped firebreaks.
Server Component errors and Client Component errors follow different propagation paths.
Last line: global-error.tsx is your last defense β€” never ship without it.

Structured Logging Architecture

Production logging in Next.js requires a unified approach across Server Components, Route Handlers, Server Actions, and Client Components. Each execution context has different capabilities and constraints.

Server-side logging should emit structured JSON with correlation IDs, request context, and severity levels. Client-side logging must batch and transport errors to a server endpoint to avoid CORS issues and ensure delivery.

The correlation ID pattern is non-negotiable for production debugging. Generate a unique ID per request in middleware, attach it to the request context via AsyncLocalStorage or headers(), and include it in every log entry and error report. This enables tracing a single user's request across all server-side operations.

Never log sensitive data β€” PII, tokens, or raw passwords. Use a sanitization layer that redacts known patterns before the log entry reaches your transport.

lib/io/thecodeforge/logging/logger.ts Β· TYPESCRIPT
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455
import { headers } from 'next/headers'

interface LogContext {
  correlationId: string
  route: string
  userId?: string
  timestamp: string
}

class StructuredLogger {
  private context: LogContext

  constructor(context: Partial<LogContext>) {
    this.context = {
      correlationId: context.correlationId || 'unknown',
      route: context.route || 'unknown',
      userId: context.userId,
      timestamp: new Date().toISOString()
    }
  }

  error(message: string, error: Error, meta?: Record<string, unknown>) {
    const entry = {
      level: 'error',
      message,
      ...this.context,
      error: {
        name: error.name,
        message: error.message,
        stack: error.stack,
        digest: (error as any).digest
      },
      ...meta
    }
    // Send to your log aggregation service
    console.error(JSON.stringify(entry))
  }

  warn(message: string, meta?: Record<string, unknown>) {
    console.warn(JSON.stringify({
      level: 'warn',
      message,
      ...this.context,
      ...meta
    }))
  }
}

export async function createLogger(route: string) {
  const headersList = await headers()
  return new StructuredLogger({
    correlationId: headersList.get('x-request-id') || crypto.randomUUID(),
    route
  })
}
⚠ Logging Anti-Patterns in Next.js 16
πŸ“Š Production Insight
Without correlation IDs, debugging a production error requires guessing which log entries relate to the failing request.
Log aggregation tools like Datadog or CloudWatch become unusable without structured context.
Rule: generate correlation IDs in middleware and thread them through every log call β€” this is table stakes for production.
🎯 Key Takeaway
Structured JSON logs with correlation IDs are the foundation of production observability.
One logger instance per request preserves context across all operations.
Last line: if you cannot trace a user's request through your logs in under 30 seconds, your logging architecture needs work.

Server Action Error Handling Patterns

Server Actions in Next.js 16 execute server-side but are invoked from client components. This creates a unique error handling challenge β€” errors must be communicated back to the client without exposing internal implementation details.

Never throw raw Error objects from Server Actions to the client. Instead, return structured error response objects with typed error codes and user-safe messages. The client component can then render appropriate UI based on the error code.

For validation errors, return field-level error maps that client components can bind directly to form inputs. For authorization errors, return a specific error code that triggers a redirect to the login flow. For unexpected errors, log the full exception server-side and return a generic error to the client.

Use Zod or similar schema validation at the Server Action boundary to catch malformed input before it reaches your business logic. This prevents a class of errors entirely and provides structured validation feedback.

app/actions/io/thecodeforge/user-actions.ts Β· TYPESCRIPT
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051
'use server'

import { z } from 'zod'
import { createLogger } from '@/lib/io/thecodeforge/logging/logger'

const UpdateProfileSchema = z.object({
  name: z.string().min(2).max(100),
  email: z.string().email(),
  bio: z.string().max(500).optional()
})

type ActionResponse<T = void> =
  | { success: true; data: T }
  | { success: false; error: { code: string; message: string; fields?: Record<string, string> } }

export async function updateProfile(
  formData: FormData
): ActionResponse<{ userId: string }> {
  const logger = await createLogger('/actions/update-profile')

  const raw = {
    name: formData.get('name'),
    email: formData.get('email'),
    bio: formData.get('bio')
  }

  const parsed = UpdateProfileSchema.safeParse(raw)

  if (!parsed.success) {
    const fields: Record<string, string> = {}
    for (const issue of parsed.error.issues) {
      fields[issue.path[0] as string] = issue.message
    }
    return {
      success: false,
      error: { code: 'VALIDATION_FAILED', message: 'Invalid input', fields }
    }
  }

  try {
    const userId = await updateUserProfile(parsed.data)
    logger.warn('Profile updated', { userId })
    return { success: true, data: { userId } }
  } catch (error) {
    logger.error('Profile update failed', error as Error, { email: parsed.data.email })
    return {
      success: false,
      error: { code: 'INTERNAL_ERROR', message: 'Failed to update profile' }
    }
  }
}
Mental Model
Server Action Error Contract
Treat Server Actions as API endpoints β€” they have an input contract, an output contract, and error codes that the client depends on.
  • Validate input with Zod at the boundary β€” reject before business logic runs
  • Return typed error responses, never throw to the client
  • Log the full exception server-side with correlation ID and input context
  • Return user-safe messages only β€” never expose stack traces, SQL errors, or internal paths
πŸ“Š Production Insight
Throwing from a Server Action causes Next.js to return a generic 500 response.
The client receives no structured error β€” just a network failure.
Rule: always return structured error objects from Server Actions β€” never throw.
🎯 Key Takeaway
Server Actions are API endpoints with typed contracts β€” treat them as such.
Validation at the boundary prevents an entire class of runtime errors.
Last line: the client should never see a raw Error object from a Server Action β€” only typed error codes.

Client-Side Error Instrumentation

Client-side errors in Next.js 16 require different instrumentation than server-side errors. The browser environment has unique failure modes β€” unhandled promise rejections, resource loading failures, hydration mismatches, and third-party script errors.

Install a global error handler for uncaught exceptions and unhandled promise rejections in a top-level Client Component or layout. This catches errors that escape React's error boundary system.

Hydration mismatches are a common source of client-side errors in Next.js. They occur when the server-rendered HTML does not match what React expects on the client. Log these with the actual vs expected content to identify the root cause β€” usually date formatting, random values, or conditional rendering based on browser-only APIs.

Batch error reports to avoid overwhelming your monitoring endpoint. Buffer errors in memory and flush them on a 5-second interval or before page unload. Use navigator.sendBeacon for unload-time reporting to ensure delivery even when the page is closing.

app/providers/ErrorInstrumentation.tsx Β· TSX
1234567891011121314151617181920212223242526272829303132333435363738394041424344
'use client'

import { useEffect } from 'react'
import { io } from '@thecodeforge/monitoring-client'

export function ErrorInstrumentation({
  children
}: {
  children: React.ReactNode
}) {
  useEffect(() => {
    // Global uncaught exception handler
    const handleError = (event: ErrorEvent) => {
      io.thecodeforge.monitoring.captureException(event.error, {
        tags: { source: 'window.onerror' },
        extra: {
          filename: event.filename,
          lineno: event.lineno,
          colno: event.colno
        }
      })
    }

    // Global unhandled promise rejection handler
    const handleRejection = (event: PromiseRejectionEvent) => {
      io.thecodeforge.monitoring.captureException(
        event.reason instanceof Error
          ? event.reason
          : new Error(String(event.reason)),
        { tags: { source: 'unhandledrejection' } }
      )
    }

    window.addEventListener('error', handleError)
    window.addEventListener('unhandledrejection', handleRejection)

    return () => {
      window.removeEventListener('error', handleError)
      window.removeEventListener('unhandledrejection', handleRejection)
    }
  }, [])

  return <>{children}</>
}
πŸ’‘Hydration Mismatch Detection
  • Hydration mismatches appear as console warnings in development β€” they are silent in production
  • Log the actual vs expected content to identify the divergence source
  • Common causes: Date.now(), Math.random(), browser-only APIs in Server Components, locale-dependent formatting
πŸ“Š Production Insight
Errors that escape React's error boundary system are invisible to standard monitoring.
Unhandled promise rejections in async event handlers bypass error.tsx entirely.
Rule: install global window.onerror and unhandledrejection handlers in your root layout β€” they catch what React boundaries miss.
🎯 Key Takeaway
React error boundaries do not catch everything β€” global handlers fill the gaps.
Batch and beacon client errors to ensure delivery during page transitions.
Last line: if you only have server-side logging, you are blind to 40% of your production errors.

Monitoring Integration and Alerting

Production error handling is incomplete without monitoring and alerting. Errors must flow from your application to a monitoring service, then to your on-call team with sufficient context to diagnose without reproducing.

Integrate Sentry, Datadog, or a similar APM tool using the official Next.js integration. These tools capture stack traces, request context, user breadcrumbs, and environment metadata automatically. Manual console.error calls supplement this but should not replace structured error capture.

Configure alerting rules based on error rate thresholds, not individual errors. A single 500 error is noise β€” a 5% error rate on a specific endpoint is an incident. Use rolling windows (5-minute or 15-minute) to avoid alert fatigue from transient spikes.

Implement error grouping to prevent alert storms during cascading failures. When a database connection pool is exhausted, every request fails with a different stack trace but the same root cause. Group by error class and route to collapse 1000 errors into one alert.

sentry.client.config.ts Β· TYPESCRIPT
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647
import * as Sentry from '@sentry/nextjs'

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: process.env.NODE_ENV === 'production' ? 0.1 : 1.0,
  replaysOnErrorSampleRate: 1.0,
  replaysSessionSampleRate: 0.05,

  beforeSend(event, hint) {
    // Filter out known non-critical errors
    const error = hint.originalException

    if (error instanceof Error) {
      // Browser extension errors
      if (error.stack?.includes('extension://')) return null
      // Network errors from ad blockers
      if (error.message.includes('Failed to fetch')) return null
    }

    // Redact sensitive data from breadcrumbs
    if (event.breadcrumbs) {
      event.breadcrumbs = event.breadcrumbs.map(bc => {
        if (bc.data?.url) {
          bc.data.url = redactUrl(bc.data.url)
        }
        return bc
      })
    }

    return event
  }
})

function redactUrl(url: string): string {
  try {
    const parsed = new URL(url)
    parsed.searchParams.forEach((_, key) => {
      if (['token', 'key', 'secret', 'password'].some(s => key.toLowerCase().includes(s))) {
        parsed.searchParams.set(key, '[REDACTED]')
      }
    })
    return parsed.toString()
  } catch {
    return url
  }
}
⚠ Alert Fatigue Prevention
πŸ“Š Production Insight
Without error grouping, a single database timeout causes 1000 individual alerts β€” your on-call team stops responding.
Alert fatigue is worse than no alerts β€” it trains engineers to ignore pages.
Rule: group by root cause, alert on rate thresholds, and review thresholds weekly.
🎯 Key Takeaway
Monitoring captures errors β€” alerting surfaces incidents.
Error rate thresholds over rolling windows prevent alert fatigue.
Last line: if your on-call team ignores 50% of pages, your alerting configuration is broken β€” not your engineers.

Graceful Degradation and User Feedback

Error handling is ultimately about user experience. A well-handled error shows the user what happened, what they can do, and when to try again. A poorly handled error shows a stack trace or a blank page.

Implement tiered fallback strategies based on error severity. For transient errors (network timeouts, rate limits), show a retry button with exponential backoff. For data errors (missing resources, permission denied), show contextual guidance. For catastrophic errors (application crash), show a static fallback page with a support link.

Error boundaries should provide a reset mechanism. The reset() function from Next.js error.tsx props re-renders the boundary's children. Use this for retry functionality, but add rate limiting to prevent infinite retry loops.

Collect user feedback at the error point. A simple 'What were you trying to do?' textarea alongside the error message provides invaluable debugging context. Store this feedback with the error report's correlation ID.

components/io/thecodeforge/ui/GracefulError.tsx Β· TSX
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455
'use client'

import { useState } from 'react'

interface GracefulErrorProps {
  error: Error & { digest?: string }
  reset: () => void
  severity: 'transient' | 'data' | 'critical'
}

export function GracefulError({
  error,
  reset,
  severity
}: GracefulErrorProps) {
  const [retryCount, setRetryCount] = useState(0)
  const [feedback, setFeedback] = useState('')
  const maxRetries = 3

  const handleRetry = () => {
    if (retryCount >= maxRetries) return
    setRetryCount(prev => prev + 1)
    // Exponential backoff: 1s, 2s, 4s
    const delay = Math.pow(2, retryCount) * 1000
    setTimeout(reset, delay)
  }

  if (severity === 'transient') {
    return (
      <div className="error-transient">
        <p>Something went wrong. This is usually temporary.</p>
        <button
          onClick={handleRetry}
          disabled={retryCount >= maxRetries}
        >
          {retryCount >= maxRetries ? 'Max retries reached' : 'Retry'}
        </button>
      </div>
    )
  }

  return (
    <div className="error-critical">
      <h2>We hit an unexpected error</h2>
      <p>Our team has been notified. Error ID: {error.digest}</p>
      <textarea
        placeholder="What were you trying to do?"
        value={feedback}
        onChange={e => setFeedback(e.target.value)}
      />
      <button onClick={reset}>Try again</button>
      <a href="/support">Contact support</a>
    </div>
  )
}
Mental Model
Error UX Severity Model
Not all errors deserve the same response β€” match the UI to the failure's recoverability.
  • Transient errors (network, rate limit): retry button with exponential backoff β€” user can self-recover
  • Data errors (404, forbidden): contextual guidance with next steps β€” user needs different input
  • Critical errors (crash, unhandled): static fallback with support link β€” user cannot self-recover
  • Always show error digest or ID β€” enables support teams to correlate user reports with monitoring data
πŸ“Š Production Insight
Showing raw error messages to users causes confusion and erodes trust.
Showing generic 'Something went wrong' without recovery options causes abandonment.
Rule: match error UI severity to recoverability β€” give users a path forward, not just a problem statement.
🎯 Key Takeaway
Error handling is a UX problem, not just an engineering problem.
Tiered fallbacks match error severity to user recoverability.
Last line: if your error page has no retry button and no support link, you are losing users on every failure.
πŸ—‚ Error Handling Approaches in Next.js 16
Trade-offs across different error handling strategies
ApproachScopeProsConsUse When
error.tsx boundaryRoute segmentAutomatic, scoped, provides reset()Only catches render-phase errorsDefault for all route segments
try/catch in Server ActionsSingle actionFull control, typed responsesMust handle manually per actionAll Server Actions with user input
Global error handlerEntire appCatches unhandled rejectionsNo React context availableRoot layout Client Component
middleware error handlingRequest pipelineIntercepts before renderingCannot render React UIAuth failures, rate limiting
Sentry integrationFull stackAutomatic capture, grouping, alertingCost at scale, sampling trade-offsAll production applications

🎯 Key Takeaways

  • Next.js 16 error boundaries are route-segment-scoped β€” each error.tsx catches its segment and children
  • global-error.tsx is mandatory β€” without it, root crashes render blank white pages
  • Structured logging with correlation IDs is the foundation of production observability
  • Server Actions must return structured error responses β€” never throw raw Error objects to the client
  • Alert on error rate thresholds over rolling windows to prevent alert fatigue
  • Error handling is a UX problem β€” match fallback severity to user recoverability

⚠ Common Mistakes to Avoid

    βœ•Swallowing errors silently in Server Components
    Symptom

    Empty UI sections with no error indication. No errors appear in monitoring. Users see incomplete pages with no feedback.

    Fix

    Remove inline try/catch blocks from Server Components. Let errors propagate to error.tsx boundaries. Log all errors server-side before the boundary renders fallback UI.

    βœ•Missing global-error.tsx at the app root
    Symptom

    Root-level crashes render a blank white page. No retry mechanism. No error message. No monitoring capture.

    Fix

    Create app/global-error.tsx as a Client Component with 'use client' directive. Include error logging, a user-friendly message, and a retry button that calls window.location.reload().

    βœ•Throwing raw Error objects from Server Actions to the client
    Symptom

    Client receives generic 500 responses with no structured error data. No way to show field-level validation errors or typed error messages.

    Fix

    Return structured error response objects with typed codes and user-safe messages. Use the pattern { success: false, error: { code, message, fields? } } for all Server Action responses.

    βœ•Using console.log for production logging
    Symptom

    Logs are unstructured, not queryable, and lack correlation IDs. Cannot trace a user's request across multiple operations.

    Fix

    Implement structured JSON logging with correlation IDs, route context, and severity levels. Use a dedicated logger class that emits queryable log entries to your aggregation service.

    βœ•Alerting on individual errors instead of error rates
    Symptom

    Alert fatigue from hundreds of individual error notifications. On-call team starts ignoring pages. Real incidents get missed in the noise.

    Fix

    Configure alerting rules based on error rate thresholds over rolling windows (5 or 15 minutes). Group errors by error class and route. Set up escalation tiers based on severity.

Interview Questions on This Topic

  • QHow do error boundaries in Next.js 16 differ from standard React error boundaries?Mid-levelReveal
    Next.js 16 error boundaries are route-segment-scoped. Each route segment can define an error.tsx that catches errors from all children in that segment. Server Component errors propagate through the RSC tree to the nearest error.tsx, while Client Component errors follow standard React boundary rules. Next.js also provides global-error.tsx for root-level catches and a reset() prop for retry functionality. Streaming complicates error handling β€” errors after initial HTML streaming render fallbacks within the partially-rendered page, not full page replacements.
  • QWhat is the correlation ID pattern and why is it critical for production error handling?Mid-levelReveal
    Correlation ID is a unique identifier generated per request in middleware and threaded through every log entry, error report, and downstream service call. It enables tracing a single user's request across all server-side operations, even when those operations span multiple Server Components, API calls, and background jobs. Without correlation IDs, debugging production errors requires guessing which log entries relate to the failing request β€” making log aggregation tools effectively unusable for incident response.
  • QWhy should you never throw raw Error objects from Server Actions to the client?SeniorReveal
    Throwing from a Server Action causes Next.js to return a generic 500 response with no structured error data. The client cannot distinguish between validation errors, authorization errors, and internal failures. Instead, return structured error response objects with typed error codes and user-safe messages. Log the full exception server-side with the correlation ID and input context. This pattern enables the client to render appropriate UI β€” field-level validation errors, login redirects, or generic fallbacks β€” without exposing internal implementation details.
  • QHow would you prevent alert fatigue in a production Next.js application?SeniorReveal
    Alert on error rate thresholds over rolling windows instead of individual errors. Group errors by error class and route to collapse cascading failures into single alerts. Configure escalation tiers β€” page on-call only for P1 error rate spikes, Slack for P2, dashboard for P3. Review and tune alert thresholds weekly to prevent staleness. Implement error grouping in your monitoring tool so that 1000 timeouts from the same root cause become one grouped alert with a count, not 1000 individual alerts.
  • QWhat is the difference between error.tsx and global-error.tsx in Next.js 16?JuniorReveal
    error.tsx is route-segment-scoped β€” it catches errors from its segment and all child segments. It can be a Server or Client Component. global-error.tsx sits at the app/ root and catches errors that escape all nested error boundaries. It must be a Client Component because it replaces the entire root layout. global-error.tsx is the last line of defense β€” if it is missing, a root-level crash renders a blank white page with no recovery option.

Frequently Asked Questions

Should error.tsx be a Server or Client Component?

error.tsx must be a Client Component β€” it uses React state and lifecycle methods (the reset function). Add 'use client' at the top of every error.tsx file. global-error.tsx also must be a Client Component. The error prop passed to these components contains the Error object with an optional digest for server-side correlation.

How do I handle errors in Server Components that fetch data?

Let the error propagate to the nearest error.tsx boundary. Do not wrap data fetching in inline try/catch blocks that return empty arrays or null β€” this silently hides failures. If you need to log the error before the boundary catches it, use a try/catch that logs and then re-throws. The error.tsx boundary will render the fallback UI, and your monitoring will capture the exception with full context.

What sampling rate should I use for Sentry in production?

Use 0.1 (10%) for tracesSampleRate in production to balance cost and visibility. Set replaysOnErrorSampleRate to 1.0 to capture full session replays for every error. Set replaysSessionSampleRate to 0.01-0.05 for general session monitoring. Adjust based on your traffic volume and Sentry plan limits β€” higher traffic sites can use lower rates without losing incident visibility.

How do I handle hydration mismatch errors in Next.js 16?

Hydration mismatches occur when server-rendered HTML does not match what React expects on the client. Common causes: Date.now(), Math.random(), browser-only APIs in Server Components, and locale-dependent formatting. Fix by ensuring deterministic rendering β€” use suppressHydrationWarning on specific elements for known differences, or move browser-dependent logic into Client Components with useEffect. Log hydration mismatches in development to catch them before production.

Can I use middleware for error handling in Next.js 16?

Middleware can handle errors that occur before rendering β€” authentication failures, rate limiting, and request validation. It cannot render React UI, so it should return JSON responses or redirects for errors. Use middleware for early rejection (401, 429) and let rendering-phase errors flow to error.tsx boundaries. The two layers are complementary β€” middleware catches request-level errors, error.tsx catches render-level errors.

πŸ”₯
Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

← PreviousNext.js 16 + React 19 Complete Migration GuideNext β†’How I Generate 50+ shadcn Components Faster with AI
Forged with πŸ”₯ at TheCodeForge.io β€” Where Developers Are Forged