Junior 4 min · April 14, 2026

Next.js 16 Server Component Errors — Why They Vanish

Silent try/catch black-holed 23% of dashboard requests.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
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
Plain-English First

Error handling in Next.js 16 is like having a fire department for your application. Instead of letting small sparks (bugs) burn down your entire site, you install smoke detectors (error boundaries), sprinklers (fallback UI), and a dispatch system (logging) that alerts you exactly where the fire started and how to put it out. The goal is to never let the user see a blank screen or a cryptic crash.

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.tsxTSX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
'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>
  )
}
Error Boundary Nesting Model
  • 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.tsTYPESCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
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
  • Never use console.log in production — it lacks structure and is not queryable in log aggregators
  • Never log raw request/response bodies — they contain PII, tokens, and secrets
  • Never create a new logger instance per log call — reuse per-request instances to preserve correlation ID
  • Never log in hot loops inside Server Components — it blocks rendering and inflates log volume
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.tsTYPESCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
'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' }
    }
  }
}
Server Action Error Contract
  • 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.tsxTSX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
'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.tsTYPESCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
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
  • Never alert on individual errors — alert on error rate thresholds over rolling windows
  • Group errors by error class and route, not by unique stack trace
  • Set up escalation tiers: page on-call only for P1 error rate spikes, Slack for P2, dashboard for P3
  • Review and tune alert thresholds weekly — stale thresholds cause alert fatigue and ignored pages
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.tsxTSX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
'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>
  )
}
Error UX Severity Model
  • 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.
● Production incidentPOST-MORTEMseverity: high

Silent Server Component Failures Black-Holing 23% of Dashboard Requests

Symptom
Users 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.
Assumption
The team assumed the upstream API was intermittently returning empty responses. They spent two weeks optimizing API retry logic.
Root cause
A 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.
Fix
Removed 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 UI
  • Connection pool exhaustion is a slow-building failure — monitor utilization trends, not just current state
  • Empty 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 scenarios5 entries
Symptom · 01
User sees blank white page with no error message
Fix
Check global-error.tsx — if missing, Next.js renders unstyled fallback. Add it to app/ root immediately.
Symptom · 02
Error boundary catches but shows stale/frozen data
Fix
Call reset() from error.tsx props to reset the boundary. Ensure error state does not cache previous successful response.
Symptom · 03
Server Component error not appearing in monitoring
Fix
Verify logging runs before any try/catch. Use console.error with structured JSON — plain console.error loses context in production log aggregation.
Symptom · 04
Server Action error returns generic 500 to client
Fix
Return structured error objects from Server Actions using { error: { code, message } } pattern. Never throw raw Error objects to the client.
Symptom · 05
Error only occurs in production, not in development
Fix
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 Error Quick Debug CommandsImmediate diagnostic commands for production error triage
Server Component renders empty without error
Immediate action
Check server logs for unhandled promise rejections
Commands
kubectl logs -l app=nextjs --tail=200 | grep -i 'unhandled\|error\|reject'
next dev --inspect
Fix now
Add process.on('unhandledRejection', handler) in instrumentation.ts
Client-side error boundary not firing+
Immediate action
Verify 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 now
Ensure error.tsx is a Client Component with 'use client' directive
Logging service receiving no error events in production+
Immediate action
Test 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 now
Verify SENTRY_DSN is set in production environment, not just .env.local
Error logs missing request context and user ID+
Immediate action
Implement 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 now
Add X-Request-ID header generation in middleware.ts and pass via headers()
Error Handling Approaches in Next.js 16
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

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

Common mistakes to avoid

5 patterns
×

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 PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
How do error boundaries in Next.js 16 differ from standard React error b...
Q02SENIOR
What is the correlation ID pattern and why is it critical for production...
Q03SENIOR
Why should you never throw raw Error objects from Server Actions to the ...
Q04SENIOR
How would you prevent alert fatigue in a production Next.js application?
Q05JUNIOR
What is the difference between error.tsx and global-error.tsx in Next.js...
Q01 of 05SENIOR

How do error boundaries in Next.js 16 differ from standard React error boundaries?

ANSWER
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.
FAQ · 5 QUESTIONS

Frequently Asked Questions

01
Should error.tsx be a Server or Client Component?
02
How do I handle errors in Server Components that fetch data?
03
What sampling rate should I use for Sentry in production?
04
How do I handle hydration mismatch errors in Next.js 16?
05
Can I use middleware for error handling in Next.js 16?
🔥

That's React.js. Mark it forged?

4 min read · try the examples if you haven't

Previous
Next.js 16 + React 19 Complete Migration Guide
41 / 47 · React.js
Next
How I Generate 50+ shadcn Components Faster with AI