Error Tracking in React with the Sentry SDK

React's component model is great for building UIs and terrible for surfacing the errors inside them. A thrown exception during render unmounts your whole tree and shows the user a blank screen — and unless you're capturing it, you'll never know it happened. This guide sets up production-grade error tracking in a React app using the Sentry SDK, pointed at LightTrace.

By the end you'll capture render errors, event-handler errors, and unhandled promise rejections, with readable stack traces that map back to your original source.

Install and initialize the SDK

Add the SDK and initialize it once, before your app renders. Because LightTrace speaks the Sentry protocol, you use the standard @sentry/react package and change only the dsn.

npm install @sentry/react

// src/main.tsx
import * as Sentry from "@sentry/react";
import { createRoot } from "react-dom/client";
import App from "./App";

Sentry.init({
  dsn: "https://<key>@your-lighttrace-host/1",
  environment: import.meta.env.MODE,
  release: `web@${import.meta.env.VITE_APP_VERSION}`,
  tracesSampleRate: 1.0,
});

createRoot(document.getElementById("root")!).render(<App />);

That single init installs global handlers for uncaught errors and unhandled rejections. But render errors need one more piece: an error boundary.

Catch render errors with an Error Boundary

React only reports render-phase errors through an Error Boundary. The SDK ships one that reports to LightTrace automatically and lets you show a fallback UI.

import * as Sentry from "@sentry/react";

export function App() {
  return (
    <Sentry.ErrorBoundary fallback={<CrashScreen />} showDialog>
      <Routes />
    </Sentry.ErrorBoundary>
  );
}

Upload source maps so traces are readable

In production your JavaScript is minified, so a raw stack trace points at index-4f9a.js:1:52210 — useless. Source maps map that back to your real .tsx files. With Vite, enable them and upload on each build:

// vite.config.ts
export default defineConfig({
  build: { sourcemap: true },
});

Then upload the maps in CI as part of your deploy. Our Vite source maps guide walks through the exact pipeline; the same idea applies if you're on Next.js.

Add context that makes debugging fast

Raw errors are a starting point. The real speed-up comes from context — who hit it, what they did, and which release introduced it. Set the user and add breadcrumbs at meaningful moments:

Sentry.setUser({ id: user.id, email: user.email });

Sentry.addBreadcrumb({
  category: "checkout",
  message: "Clicked place order",
  level: "info",
});

Now every captured error arrives with the breadcrumb trail that led to it, so you can reproduce the exact path instead of guessing.

Common React errors worth watching

A few React-specific errors show up constantly in production. Each has its own fix:

• Maximum update depth exceeded — an infinite render loop, usually a setState in render.
• React hydration errors — server and client HTML diverged.
• Cannot read properties of undefined — the single most common runtime TypeError.

With tracking in place, these stop being mystery blank screens and become issues with a stack trace and a user count.

That's the full setup: SDK initialized, error boundaries catching render crashes, source maps making traces readable, and context making them fast to fix. For the framework-agnostic version of this pattern, see how to add error tracking to any app.