Chapter 11: Error Handling, Logging, and Monitoring in Production

Welcome to Chapter 11! In the exciting world of building React applications, it’s easy to get caught up in creating beautiful UIs and powerful features. But what happens when things go wrong? Because, let’s be honest, they will go wrong. Users might encounter unexpected data, network issues, or even bugs we didn’t catch during development.

In this chapter, we’re going to transform from mere developers into resilient application guardians! We’ll dive deep into the crucial practices of robust error handling, structured logging, and effective monitoring in production React applications. You’ll learn how to gracefully handle errors, gather crucial information when they occur, and keep a watchful eye on your application’s health, ensuring a smooth experience for your users and peace of mind for you and your team.

Before we begin, a basic understanding of React components, state, and lifecycle methods will be helpful. If you’ve been following along, you’re perfectly set! Let’s make our applications not just functional, but also incredibly robust.

The Unseen Heroes: Error Handling, Logging, and Monitoring

Imagine your React application is a sleek, high-performance race car. Error handling is like the car’s advanced safety system – airbags, crumple zones, traction control – designed to minimize damage and keep the driver (user) safe when something unexpected happens. Logging is the black box recorder, meticulously documenting every event and anomaly, so mechanics (developers) can diagnose problems after the race. Monitoring is the pit crew, constantly checking telemetry, tire pressure, and engine health in real-time to catch potential issues before they become critical.

Ignoring these aspects in a production environment is like sending that race car onto the track without safety features, a black box, or a pit crew. When a problem arises, users face a crashed application, developers are left guessing what went wrong, and the entire system becomes unreliable.

Why It Matters: Production Problems Solved

1. User Experience (UX) Resilience: Users hate seeing a blank screen or a broken UI. Proper error handling ensures that even when a part of your application fails, the rest can continue to function, or at least present a user-friendly message instead of a cryptic crash.
2. Faster Debugging & Resolution: When an error occurs, detailed logs and monitoring alerts provide immediate insights into what happened, where it happened, and why. This drastically reduces the time spent on debugging and helps you fix issues quickly.
3. Proactive Problem Detection: Monitoring tools can alert you to performance bottlenecks, increasing error rates, or other anomalies before they impact a large number of users, allowing you to intervene proactively.
4. Security & Data Integrity: Errors, especially unhandled ones, can sometimes expose sensitive information or lead to unexpected states. Robust error handling and logging help maintain application integrity and can provide clues for security incidents.

Let’s explore the core concepts that make this possible.

React Error Boundaries: Catching UI Crashes

In React, an error in a component’s render phase, lifecycle methods, or constructors can crash your entire application. Before React 16, there was no built-in way to gracefully handle these errors within the component tree. This meant a small bug in one component could take down your whole UI!

What are Error Boundaries? Error Boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. They are like a safety net for your UI.

Why are they important? They prevent a single UI error from “breaking” the entire user experience. Instead of a white screen, your user sees a polite “Something went wrong” message.

What failures occur if ignored? Without Error Boundaries, an uncaught error in a deeply nested component would unmount the entire React component tree, leading to a completely blank page or a broken UI for the user. This is a terrible user experience and makes debugging very difficult as the UI provides no clues.

Limitations: Error Boundaries only catch errors in:

• Render phase
• Lifecycle methods (e.g., componentDidMount, componentDidUpdate)
• Constructors They do not catch errors in:
• Event handlers (e.g., onClick, onChange)
• Asynchronous code (setTimeout, Promise.then)
• Server-side rendering
• Errors thrown in the Error Boundary itself

Don’t worry, we’ll cover how to handle these other types of errors too!

Global Error Handling: Beyond React’s Boundaries

Since Error Boundaries have limitations, we need mechanisms to catch errors that occur outside of the React component lifecycle. This is where browser-native APIs come into play.

• window.onerror: This global event handler catches uncaught JavaScript errors that bubble up to the window object. It’s excellent for capturing syntax errors, runtime errors, and errors from third-party scripts that aren’t within your React component tree.
• window.onunhandledrejection: This global event handler catches Promises that are rejected but don’t have a .catch() handler. As modern JavaScript relies heavily on Promises (e.g., fetch, async/await), this is crucial for catching network errors or other async operation failures that aren’t explicitly handled.

Together, these two give us a robust safety net for almost any error occurring in the browser environment.

Structured Logging: More Than console.log

While console.log is great for development, it falls short in production. Imagine sifting through hundreds of console.log statements from various users trying to debug a single issue!

What is Structured Logging? Structured logging means logging data in a consistent, machine-readable format (like JSON) rather than plain text. Each log entry includes metadata such as:

• Timestamp: When did it happen?
• Level: Is it an info, warn, error, or debug message?
• Message: A human-readable description.
• Context: User ID, component name, request ID, error stack trace, browser info, etc.

Why is it important?

• Searchability: Easily filter and search logs for specific users, errors, or components.
• Analysis: Tools can parse structured logs to create dashboards, alerts, and aggregate error counts.
• Consistency: Ensures all relevant information is present for debugging.

What failures occur if ignored? Without structured logging, you end up with chaotic, unsearchable logs that are nearly useless for diagnosing complex production issues. You’d spend more time trying to find the error than fixing it.

Monitoring and User-Safe Messaging: Observability & Empathy

Real User Monitoring (RUM): RUM tools (like Sentry, LogRocket, Datadog, New Relic) collect data about how real users interact with your application. They combine error reporting with performance metrics, session replays, and user journey tracking. This gives you a complete picture of your application’s health and user experience in the wild.

User-Safe Messaging: When an error occurs, displaying a cryptic technical message to the user is a bad idea. Instead, provide:

• A polite, non-technical message (e.g., “Oops! Something went wrong on our end. Please try again later.”).
• An option to report the issue (if applicable).
• A unique error ID (which corresponds to a log entry) that the user can provide to support.
• Instructions on what to do next (e.g., refresh the page, contact support).

This approach prioritizes user empathy and helps in debugging by providing a link between the user’s report and your backend logs.

Diagram: Error Handling Flow

Let’s visualize how errors might flow through our application and get handled:

This diagram illustrates how errors from different sources are caught and then flow to a logging service for recording and eventual monitoring/alerting, while also providing user-friendly feedback.

Step-by-Step Implementation: Building a Robust System

Let’s put these concepts into practice. We’ll start with an Error Boundary, then integrate a simple logging utility, and finally hook up global error handlers.

Step 1: Creating a Basic Logging Utility

First, let’s create a very basic (but extensible!) logging utility. In a real application, this would integrate with a service like Sentry or LogRocket. For now, it will simulate sending logs.

Create a file src/utils/logger.ts (or .js if not using TypeScript):

// src/utils/logger.ts
type LogLevel = 'info' | 'warn' | 'error' | 'debug';

interface LogContext {
  component?: string;
  userId?: string;
  requestId?: string;
  [key: string]: any; // Allow any additional context
}

const isProduction = process.env.NODE_ENV === 'production';

// Version: 1.0.0 (as of 2026-02-11)
const logger = {
  log: (level: LogLevel, message: string, context?: LogContext) => {
    const timestamp = new Date().toISOString();
    const logEntry = {
      timestamp,
      level: level.toUpperCase(),
      message,
      ...context,
    };

    if (!isProduction) {
      // In development, log to console for immediate feedback
      switch (level) {
        case 'error':
          console.error('[APP_LOG]', logEntry);
          break;
        case 'warn':
          console.warn('[APP_LOG]', logEntry);
          break;
        case 'info':
          console.info('[APP_LOG]', logEntry);
          break;
        case 'debug':
          console.debug('[APP_LOG]', logEntry);
          break;
      }
    } else {
      // In production, send to a real logging service (e.g., Sentry, LogRocket)
      // For this example, we'll just log to console, but imagine this is an API call
      // Example: Sentry.captureException(new Error(message), { extra: logEntry });
      // Example: fetch('/api/log', { method: 'POST', body: JSON.stringify(logEntry) });
      console.log('[PROD_LOG_SIMULATED]', logEntry); // Simulate sending to a service
    }
  },

  error: (message: string, error: Error, context?: LogContext) => {
    logger.log('error', message, {
      ...context,
      errorName: error.name,
      errorMessage: error.message,
      errorStack: error.stack,
    });
  },

  warn: (message: string, context?: LogContext) => {
    logger.log('warn', message, context);
  },

  info: (message: string, context?: LogContext) => {
    logger.log('info', message, context);
  },

  debug: (message: string, context?: LogContext) => {
    if (!isProduction) { // Only log debug in development
      logger.log('debug', message, context);
    }
  },
};

export default logger;

Explanation:

• We define LogLevel and LogContext interfaces for type safety and structured data.
• The isProduction flag helps us decide whether to console.log directly (dev) or simulate sending to a service (prod).
• The log method is the core, formatting our log entry with a timestamp, level, message, and any provided context.
• Helper methods (error, warn, info, debug) make it easier to log specific types of messages, especially error which automatically includes error details.
• In a real-world scenario, the else block for isProduction would contain code to send this structured log to an actual error monitoring service.

Step 2: Implementing a React Error Boundary Component

Now, let’s create our ErrorBoundary component. This will be a class component because functional components (as of React 18 / 2026) cannot implement getDerivedStateFromError or componentDidCatch.

Create a file src/components/ErrorBoundary.tsx (or .js):

// src/components/ErrorBoundary.tsx
import React, { Component, ErrorInfo, ReactNode } from 'react';
import logger from '../utils/logger'; // Our new logger utility

interface Props {
  children: ReactNode;
  fallback?: ReactNode; // Optional custom fallback UI
}

interface State {
  hasError: boolean;
  error: Error | null;
}

// React Version: 18.2.0 (Stable as of 2026-02-11)
class ErrorBoundary extends Component<Props, State> {
  public state: State = {
    hasError: false,
    error: null,
  };

  // static getDerivedStateFromError is called when an error is thrown
  // It returns a state update to show the fallback UI
  public static getDerivedStateFromError(error: Error): State {
    console.error("ErrorBoundary: static getDerivedStateFromError caught an error:", error);
    return { hasError: true, error: error };
  }

  // componentDidCatch is called after an error has been thrown
  // It's used for logging the error information
  public componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    console.error("ErrorBoundary: componentDidCatch caught an error:", error, errorInfo);
    // Here, we send the error to our logging service
    logger.error('Caught an error in React component tree', error, {
      componentStack: errorInfo.componentStack,
      componentName: 'ErrorBoundary', // Context for logger
    });
  }

  public render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      if (this.props.fallback) {
        return this.props.fallback;
      }
      return (
        <div style={{ padding: '20px', border: '1px solid red', borderRadius: '5px', backgroundColor: '#ffe6e6' }}>
          <h2>Oops! Something went wrong.</h2>
          <p>We're sorry for the inconvenience. Our team has been notified.</p>
          <p>Error details: {this.state.error?.message}</p>
          {/* In production, you might hide error details or provide a unique reference ID */}
          {process.env.NODE_ENV !== 'production' && (
            <details style={{ whiteSpace: 'pre-wrap', marginTop: '10px' }}>
              <summary>Error Stack (Dev Only)</summary>
              <code>{this.state.error?.stack}</code>
            </details>
          )}
          <button
            onClick={() => window.location.reload()}
            style={{ marginTop: '15px', padding: '10px 15px', cursor: 'pointer' }}
          >
            Refresh Page
          </button>
        </div>
      );
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

Explanation:

• ErrorBoundary is a class component extending React.Component.
• hasError in its state tracks whether an error has occurred.
• static getDerivedStateFromError(error): This static method is invoked after an error is thrown by a descendant component. It receives the error that was thrown and should return a value to update the state. Here, we set hasError to true and store the error object. This causes the component to re-render with the fallback UI.
• componentDidCatch(error, errorInfo): This method is invoked after an error has been thrown. It receives the error and an errorInfo object containing the component stack. This is where we perform side effects like logging the error to our logger utility. We provide context like componentStack for better debugging.
• render(): If this.state.hasError is true, we render a user-friendly fallback UI. Otherwise, we render the children components as normal. We also offer an optional fallback prop for consumers to provide their own UI.

Step 3: Using the Error Boundary

Now, let’s wrap parts of our application with the ErrorBoundary. You can wrap individual components, or even your entire application for a global fallback.

Modify src/App.tsx (or .js):

// src/App.tsx
import React, { useState } from 'react';
import ErrorBoundary from './components/ErrorBoundary';
import logger from './utils/logger'; // Our logger

// --- Component that might throw an error ---
const BuggyComponent = () => {
  const [shouldError, setShouldError] = useState(false);

  if (shouldError) {
    // Simulate an error in the render phase
    throw new Error('I am a deliberately buggy component! 💥');
  }

  const throwErrorInEventHandler = () => {
    try {
      // Errors in event handlers are NOT caught by Error Boundaries!
      // We need a try-catch or global handlers for these.
      throw new Error('Error from event handler! 🚨');
    } catch (e: any) {
      logger.error('Caught error in BuggyComponent event handler', e, {
        component: 'BuggyComponent',
        action: 'throwErrorInEventHandler',
      });
      alert(`An error occurred: ${e.message}. Check console for logs.`);
    }
  };

  return (
    <div style={{ border: '1px dashed blue', padding: '15px', margin: '20px', backgroundColor: '#e6f0ff' }}>
      <h3>Buggy Component</h3>
      <p>This component can be made to throw an error.</p>
      <button onClick={() => setShouldError(true)}>
        Trigger Render Error
      </button>
      <button onClick={throwErrorInEventHandler} style={{ marginLeft: '10px' }}>
        Trigger Event Handler Error
      </button>
      <p>Try triggering both errors and observe the difference!</p>
    </div>
  );
};

// --- Main App Component ---
function App() {
  return (
    <div className="App" style={{ fontFamily: 'Arial, sans-serif', textAlign: 'center' }}>
      <h1>Chapter 11: Error Handling Demo</h1>

      <h2>Section 1: Protected by Error Boundary</h2>
      <ErrorBoundary>
        <BuggyComponent />
      </ErrorBoundary>

      <h2>Section 2: Unprotected Component (will crash app!)</h2>
      <p>
        **Warning:** If you uncomment the `UnprotectedBuggyComponent` below and trigger its error,
        the entire application will likely crash. This demonstrates why Error Boundaries are vital!
      </p>
      {/*
      // Uncomment this to see what happens without an Error Boundary!
      <BuggyComponent />
      */}

      <p>
        Remember to open your browser's developer console to see the logs from our `logger` utility!
      </p>
    </div>
  );
}

export default App;

Explanation:

• We’ve imported our ErrorBoundary and logger.
• BuggyComponent has two buttons: one that throws an error in its render logic (which ErrorBoundary will catch) and another that throws an error in an event handler (which ErrorBoundary will not catch, but we’ve added a try-catch to log it).
• In App, we wrap BuggyComponent with ErrorBoundary. Now, if BuggyComponent throws a render error, only that section of the UI will show the fallback, and the error will be logged.
• We’ve added a commented-out section to show what happens if a BuggyComponent is not wrapped by an ErrorBoundary – the entire app crashes.

Step 4: Implementing Global Error Handlers

To catch errors outside of React’s component tree and those not caught by Error Boundaries (like event handler errors, or errors from non-React scripts), we’ll set up global handlers.

Modify src/index.tsx (or .js) – this is typically where global setup happens:

// src/index.tsx
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import logger from './utils/logger'; // Our logger

// --- Global Error Handlers (Version: 1.0.0, as of 2026-02-11) ---

// 1. Catch uncaught JavaScript errors
window.onerror = (message, source, lineno, colno, error) => {
  // Prevent default browser error handling (optional, but common for custom reporting)
  // return true;

  logger.error('Global uncaught JavaScript error', error || new Error(String(message)), {
    type: 'window.onerror',
    message: String(message),
    source,
    lineno,
    colno,
  });

  // You might also want to show a generic error toast to the user here
  // alert('A critical error occurred. Please refresh the page.');

  // Returning true prevents the browser's default error handling (e.g., logging to console)
  // For development, you might want to return false to still see browser console errors.
  return process.env.NODE_ENV === 'production';
};

// 2. Catch unhandled Promise rejections
window.onunhandledrejection = (event) => {
  // Prevent default browser error handling (optional)
  // event.preventDefault();

  logger.error('Global unhandled Promise rejection', event.reason, {
    type: 'window.onunhandledrejection',
    promise: event.promise,
  });

  // You might also want to show a generic error toast to the user here
  // alert('A network or background operation failed. Please try again.');
};

// --- React Root Render ---
const root = ReactDOM.createRoot(
  document.getElementById('root') as HTMLElement
);
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

Explanation:

• We set window.onerror to capture any uncaught JavaScript errors. We then log these using our logger utility, providing as much context as possible. We use error || new Error(String(message)) to ensure we always pass an Error object to our logger, which expects it.
• We set window.onunhandledrejection to catch any Promises that reject without a .catch() handler. This is critical for async operations. We log event.reason, which is usually the Error object or value that the Promise rejected with.
• The return true in window.onerror in production prevents the browser from logging the error to the console, allowing your custom logger to be the primary source. In development, we keep it false so you still see browser console errors.

Trying It Out

1. Start your React app: npm start or yarn start.
2. Open Developer Tools: Go to the “Console” tab.
3. Trigger Render Error: Click “Trigger Render Error” in the first BuggyComponent.
   • Observe: The component section shows the fallback UI. Your console will show logs from ErrorBoundary and our logger.
4. Trigger Event Handler Error: Click “Trigger Event Handler Error” in the first BuggyComponent.
   • Observe: The alert shows up (from our try-catch). The console shows logs from our logger (because we explicitly caught and logged it). The UI remains unaffected, as expected.
5. Simulate an unhandled Promise rejection (optional): Add this line temporarily to App.tsx outside any component function, or in a useEffect without a .catch():

   // In App.tsx or index.tsx, but not in a component's render or event handler
   // This will trigger window.onunhandledrejection
   Promise.reject(new Error('This promise was not caught!'));
   

   • Observe: Your console will show a log from window.onunhandledrejection via our logger.

You now have a foundational system for catching and logging errors in your React application!

Mini-Challenge: Enhance User Feedback

Your current ErrorBoundary shows a generic message. For better user experience, sometimes you want to give the user a specific “reference ID” they can quote if they contact support, which helps you quickly find the exact error in your logs.

Challenge: Modify the ErrorBoundary component to generate a unique, short ID (e.g., a UUID or a random string) when an error occurs. Display this ID in the fallback UI and also send it as part of the context to your logger utility.

Hint:

• You can generate a simple unique ID using Math.random().toString(36).substring(2, 9) or look into a UUID library (like uuid package, npm install uuid@^9.0.0 then import { v4 as uuidv4 } from 'uuid';).
• Store this ID in the ErrorBoundary’s state alongside hasError and error.

What to observe/learn:

• How to extend the ErrorBoundary’s state and functionality.
• The importance of tying user-facing messages to internal log entries for efficient support.
• How to provide actionable information to users while keeping technical details hidden.

Common Pitfalls & Troubleshooting

1. Error Boundaries Not Catching Async Errors or Event Handlers:

   • Pitfall: Developers often expect Error Boundaries to catch all errors. When an error occurs in an onClick handler or an async function, the Error Boundary seems to “fail.”
   • Why it happens: React’s Error Boundaries are specifically designed for errors that occur during rendering, lifecycle methods, and constructors within the component tree. Errors in event handlers or async code are outside this “render phase” and bubble up to the global window object.
   • Troubleshooting:
     • For Event Handlers: Use try-catch blocks directly within the event handler, then manually log the error.
     • For Async Code (Promises): Ensure every Promise chain has a .catch() handler. If not, window.onunhandledrejection should catch it, but it’s always best to handle rejections close to where they occur.
     • Global Fallback: Rely on window.onerror and window.onunhandledrejection as your last line of defense for anything else.

2. Over-Logging or Logging Sensitive Data:

   • Pitfall: In an eagerness to capture everything, developers might log too much information or inadvertently include sensitive user data (PII, passwords, tokens) in logs. This can lead to performance issues (excessive network requests for logs) and severe security/privacy breaches.
   • Why it happens: Lack of clear logging policies or thoughtless inclusion of entire state/props objects in log contexts.
   • Troubleshooting:
     • Policy: Establish clear guidelines on what can and cannot be logged.
     • Sanitization: Implement a log sanitization step in your logger utility to strip out or mask sensitive fields (e.g., replace password: '***' or token: '[REDACTED]').
     • Levels: Use appropriate log levels. debug logs should be disabled in production. info logs should be minimal. error logs should contain only necessary context for debugging.
     • Context: Be explicit about what context you’re adding to logs, don’t just dump entire objects.

3. Ignoring window.onerror for Non-React Errors:

   • Pitfall: Focusing solely on React Error Boundaries and forgetting about the broader browser environment. Errors from third-party scripts, browser extensions, or even malformed HTML/CSS can lead to JavaScript errors not caught by React.
   • Why it happens: Assumption that React handles all client-side errors.
   • Troubleshooting: Always set up window.onerror and window.onunhandledrejection (as we did in index.tsx) as a robust global safety net. These catch errors regardless of their origin within the browser page.

Summary

Phew! You’ve just equipped your React applications with some serious resilience and observability tools. Let’s recap the key takeaways:

• Error Boundaries (React 18+): Essential for catching errors in component rendering, lifecycle methods, and constructors. They prevent UI crashes and display a fallback UI, improving user experience.
• static getDerivedStateFromError: Used by Error Boundaries to update state and trigger a re-render with a fallback UI when an error occurs.
• componentDidCatch: Used by Error Boundaries to perform side effects, primarily logging the error to a service, after an error has been caught.
• Global Error Handlers (window.onerror, window.onunhandledrejection): Your ultimate safety net for errors occurring outside React’s lifecycle, like event handler errors, async operation failures, or third-party script errors.
• Structured Logging: Crucial for production. It involves sending machine-readable log entries with rich context (timestamp, level, user ID, stack trace) to a centralized logging service. This makes debugging and analysis vastly more efficient than console.log.
• Monitoring (RUM): Tools that combine error reporting with performance metrics and user session data, providing a holistic view of your application’s health and user experience in the wild.
• User-Safe Messaging: Always present errors to users in a friendly, non-technical way, offering clear next steps and potentially a reference ID for support.

By integrating these practices, you’re not just building features; you’re building a robust, maintainable, and user-friendly production-ready application.

What’s Next? With a solid foundation in error handling, we can now confidently move on to optimizing how our application performs and ensuring its security. In the next chapter, we’ll delve into Frontend Security, exploring common vulnerabilities and best practices to protect your React application and its users.

References

• React Docs: Error Boundaries
• MDN Web Docs: window.onerror
• MDN Web Docs: PromiseRejectionEvent
• Sentry Docs: React Error Monitoring
• LogRocket: Full Session Replay and Monitoring

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.