Claude Code & Sentry: Error Tracking und Performance Monitoring einrichten

Bugs passieren. Das ist keine Schwäche im Entwicklungsprozess — es ist eine Eigenschaft jeder komplexen Software. Die entscheidende Frage ist nicht, ob Fehler auftreten, sondern wie schnell du sie findest und verstehst. Ein ungemeldeter Produktionsfehler, der sich still durch die Nutzerbasis frisst, ist teurer als zehn Bugs im Entwicklungsumfeld.

Sentry ist das Werkzeug, das den Unterschied macht: Es fängt Fehler in Echtzeit auf, gibt dir den vollständigen Stack Trace mit Kontext — User, Browser, Umgebungsvariablen, letzter Commit — und benachrichtigt dich, bevor dein erster Nutzer eine Support-Mail schreibt. Dieser Artikel zeigt, wie du Sentry mit Claude Code in Node.js und React-Apps einrichtest: von der Installation bis zu Alerts, Source Maps und Release Tracking.

1. Warum Error Tracking?

Ohne Error Tracking lebst du in einer Informationslücke. Du weißt, dass deine App läuft — aber ob sie für alle Nutzer läuft, und unter welchen Bedingungen sie abstürzt, ist dir verborgen. console.error hilft im Entwicklungsumfeld. In der Produktion sieht es niemand.

Sentry schließt diese Lücke. Jeder unbehandelte Fehler, jede abgefangene Exception, jede langsame Transaktion wird erfasst, angereichert und an dein Dashboard gemeldet. Du siehst nicht nur dass etwas schiefgelaufen ist, sondern für wen, wann, wie oft und nach welchem Code-Commit.

2. Sentry SDK installieren und initialisieren

Für Node.js-Projekte:

npm install @sentry/node

Für React-Projekte (Browser):

npm install @sentry/react

Die Initialisierung gehört so früh wie möglich in den Application-Startup. In einer Express-App bedeutet das: vor allen anderen require-Aufrufen, vor dem Router, vor dem ersten Middleware-Stack.

// server.js — ganz oben, vor allem anderen
const Sentry = require('@sentry/node');

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 1.0, // 100% der Transaktionen tracen (im Produktionsbetrieb reduzieren)
});

Der DSN (Data Source Name) ist die Verbindungsadresse zu deinem Sentry-Projekt. Er landet in deiner .env-Datei — nie direkt im Code. Claude Code versteht diese Konvention und holt den Wert aus der Umgebung, wenn du es bittest, die Integration einzurichten.

3. Fehler capturen: try/catch und globale Handler

Sentry fängt unbehandelte Exceptions automatisch auf — aber für erwartete Fehler, die du im Code abfängst, musst du sie explizit melden:

const Sentry = require('@sentry/node');

async function fetchUserData(userId) {
  try {
    const response = await fetch(`/api/users/${userId}`);
    if (!response.ok) {
      throw new Error(`HTTP ${response.status} für User ${userId}`);
    }
    return await response.json();
  } catch (error) {
    Sentry.captureException(error);
    throw error; // weiter nach oben werfen, damit der Aufrufer es merkt
  }
}

Für Node.js gibt es zusätzlich zwei globale Handler, die Fehler auffangen, die nirgendwo sonst behandelt werden:

process.on('uncaughtException', (error) => {
  Sentry.captureException(error);
  console.error('Uncaught Exception:', error);
  process.exit(1); // sauber beenden nach unbekanntem Zustand
});

process.on('unhandledRejection', (reason) => {
  Sentry.captureException(reason);
  console.error('Unhandled Rejection:', reason);
});

Diese Handler sind ein Sicherheitsnetz, kein Ersatz für strukturiertes Error-Handling. Jeder Fehler, der hier landet, ist ein Fehler, der sonst lautlos verschwunden wäre.

4. Performance Tracing

Error Tracking ist die eine Seite. Die andere: Transaktionen, die zu langsam sind, aber keinen Fehler werfen. Ein API-Endpunkt der 8 Sekunden braucht, ein Datenbankabfrage die bei 1.000 Einträgen einbricht — kein Stack Trace, aber spürbar schlechte User Experience.

Sentry's Performance Monitoring misst diese Transaktionen automatisch. Mit Express:

const Sentry = require('@sentry/node');
const express = require('express');
const app = express();

// RequestHandler muss der erste Middleware sein
app.use(Sentry.Handlers.requestHandler());
// TracingHandler erzeugt Spans für jede Request
app.use(Sentry.Handlers.tracingHandler());

// deine Routes hier
app.get('/api/products', async (req, res) => {
  const products = await db.query('SELECT * FROM products');
  res.json(products);
});

// ErrorHandler muss nach allen Routes, aber vor anderen Error-Middlewares
app.use(Sentry.Handlers.errorHandler());

app.listen(3000);

Im Sentry-Dashboard siehst du danach für jede Route die durchschnittliche Latenz, den p75- und p95-Wert, und welche Datenbankabfragen innerhalb der Transaktion wie lange gedauert haben. Das ist die Information, die du brauchst, um Bottlenecks zu priorisieren — nicht nach Bauchgefühl, sondern nach Messwert.

5. Source Maps

Minifizierter Production-Code macht Stack Traces unlesbar. Zeile 1, Spalte 48291 in bundle.min.js hilft niemandem. Source Maps lösen das: Sie übersetzen den minifizierten Stack Trace zurück auf den Originalcode — Dateiname, Zeilennummer, Variablenname.

Mit Webpack:

// webpack.config.js
const { sentryWebpackPlugin } = require('@sentry/webpack-plugin');

module.exports = {
  devtool: 'source-map',
  plugins: [
    sentryWebpackPlugin({
      authToken: process.env.SENTRY_AUTH_TOKEN,
      org: process.env.SENTRY_ORG,
      project: process.env.SENTRY_PROJECT,
    }),
  ],
};

Das Plugin lädt die Source Maps automatisch beim Build-Prozess zu Sentry hoch. Im Produktions-Bundle landen sie nicht — sie werden nur intern von Sentry für die Stack-Trace-Auflösung verwendet.

6. User Context setzen

Ein Fehler ist informativ. Ein Fehler mit dem Wissen, dass er bei einem bestimmten Nutzertyp dreimal häufiger auftritt, ist ein Prioritätssignal. Sentry erlaubt es, jedem Event einen User-Kontext mitzugeben:

// nach dem Login des Nutzers setzen
Sentry.setUser({
  id: user.id,
  email: user.email,
  username: user.username,
  // kein Passwort, kein Token, keine sensitiven Felder
});

// beim Logout wieder löschen
Sentry.setUser(null);

Im Sentry-Dashboard kannst du danach nach user.id filtern und siehst alle Events, die dieser Nutzer ausgelöst hat — in chronologischer Reihenfolge, mit Browser, OS und Session-Dauer. Das ist die Information, die du für den Support brauchst, ohne den Nutzer fragen zu müssen.

7. Alerts und Notifications

Ein Dashboard, das niemand offen hat, hilft nichts. Alerts bringen Sentry zu dir — per E-Mail, Slack, PagerDuty oder Webhook. Im Sentry-Interface unter Alerts → Create Alert konfigurierst du Regeln:

• Issue Alert: Benachrichtigung beim ersten Auftreten eines neuen Fehlers, oder wenn ein bekannter Fehler nach einer definierten Anzahl Events eskaliert
• Metric Alert: Benachrichtigung wenn ein Schwellenwert überschritten wird — z. B. mehr als 5 Errors pro Minute, oder p95-Latenz über 2 Sekunden
• Uptime Alert: Benachrichtigung wenn ein Endpunkt nicht mehr antwortet

Für Teams empfiehlt sich ein zweistufiges Modell: eine Slack-Benachrichtigung für neue Issues (informativ, kein Handlungsdruck), und eine PagerDuty-Eskalation wenn ein Fehler eine bestimmte Häufigkeitsschwelle überschreitet (handlungspflichtig).

8. Sentry für React: ErrorBoundary

In React-Apps fangen normale Try-Catch-Blöcke keine Render-Fehler auf. Dafür gibt es Error Boundaries — Klassen-Komponenten, die Fehler im Component-Tree abfangen und einen Fallback rendern statt einen weißen Bildschirm.

Sentry liefert eine fertige ErrorBoundary-Komponente mit:

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

// In der App-Root, um den gesamten Component-Tree zu schützen
function App() {
  return (
    <Sentry.ErrorBoundary
      fallback={<p>Ein Fehler ist aufgetreten. Bitte lade die Seite neu.</p>}
      showDialog // optionales User-Feedback-Formular von Sentry
    >
      <Router>
        <Routes />
      </Router>
    </Sentry.ErrorBoundary>
  );
}

Du kannst mehrere ErrorBoundaries verschachteln: eine globale für die gesamte App, und spezifischere für kritische Bereiche wie den Checkout-Flow oder den Login. So bleibt der Rest der App funktionsfähig, wenn ein einzelner Bereich abstürzt.

9. Release Tracking

Wann ist ein Fehler zum ersten Mal aufgetreten? Nach welchem Deployment? Release Tracking verbindet jeden Sentry-Event mit dem Git-Commit, der zum Zeitpunkt des Fehlers deployed war. Das macht die Ursachensuche drastisch schneller: statt den gesamten Code-History zu durchsuchen, weißt du genau, in welchem Commit der Fehler eingeführt wurde.

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  release: process.env.SENTRY_RELEASE, // z.B. der Git-SHA: 'abc1234'
  tracesSampleRate: 1.0,
});

In der CI/CD-Pipeline setzt du SENTRY_RELEASE auf den aktuellen Git-Commit-Hash:

# In GitHub Actions oder deinem Deploy-Script
SENTRY_RELEASE=$(git rev-parse --short HEAD)
npx @sentry/cli releases new "$SENTRY_RELEASE"
npx @sentry/cli releases set-commits "$SENTRY_RELEASE" --auto
npx @sentry/cli releases finalize "$SENTRY_RELEASE"

Im Sentry-Dashboard siehst du danach unter Releases für jeden Commit, welche neuen Fehler eingeführt wurden und welche bestehenden Fehler verschwunden sind. Das ist das Qualitätssignal, das Deployments von Hoffnung in Messung verwandelt.

Zwei verwandte Artikel, die auf diesem Thema aufbauen:

• Claude Code Debugging — Stack Traces analysieren und Root-Cause finden
• Claude Code für Unternehmen — Deployment, Zugriffskontrolle und Team-Workflows