Woher weißt du, dass deine App down ist?

Was es ist und warum es zählt

Eine App zu überwachen heißt, zu wissen, dass sie kaputt ist, bevor es dir jemand sagt. Ohne Monitoring merkst du erst am Morgen, dass die Website nachts ausgefallen ist. Und oft schreibt dir niemand: Wer die App kaputt vorfindet, schließt sie einfach.

Für mich besteht Monitoring aus drei Teilen, die zusammenarbeiten:

• Der Check von außen: ein Dienst, der alle paar Minuten deine Adresse öffnet, so wie es ein Nutzer tun würde, und schaut, ob sie antwortet.
• Das Fehlerprotokoll: der Ort, an dem jeder Fehler der App landet, mit dem Stack Trace, also der Codezeile, an der es kaputtgegangen ist.
• Die Benachrichtigung: die Mail oder die Push-Nachricht aufs Handy, die du bekommst, wenn einer der beiden etwas findet.

Der Check muss außerhalb deiner App laufen: Wenn die App down ist, kann sie es dir nicht selbst sagen. Das Fehlerprotokoll dagegen zeigt dir, was kaputtgeht, auch wenn die App antwortet.

Und wenn du Claude Code mit dem Fehlerprotokoll verbindest, fängst du beim Alarm nicht bei null an.

1. Was ich nutze

Ich nutze zwei Dienste. Es sind nicht die einzigen: Mit anderen läuft es genauso.

Für die Fehler: Sentry

Jeder Fehler der App landet dort mit seinem Stack Trace, und von dort kommen die Benachrichtigungen. Der kostenlose Plan heißt Developer: Er ist für einen einzigen Nutzer und schickt die Benachrichtigungen per E-Mail.

Für den Check alle 5 Minuten: UptimeRobot

Er öffnet deine Adresse und benachrichtigt dich, wenn sie nicht antwortet, per E-Mail und mit einer Push-Nachricht in der Handy-App. Kostenloser Plan: 50 Monitore, Check alle 5 Minuten; die Nutzungsbedingungen prüfst du auf ihrer Website.

2. Die halbe Stunde

Das machst du nur einmal, in etwa einer halben Stunde, wenn die App schon online ist.

Sentry in der App

1. Leg auf Sentry ein Projekt an. Es zeigt dir den DSN, den Schlüssel des Projekts: Das ist die Adresse, an die deine App ihre Fehler schickt. Du findest ihn wieder in den Projekteinstellungen unter Client Keys (DSN).
2. Kopier ihn und schreib Claude Code:

Bau Sentry in diese App ein, mit dem DSN, den ich dir gebe, in einer Umgebungsvariable und nicht im Code. Dann lös einen Testfehler aus und sag mir, wie ich prüfe, dass er angekommen ist.

Der Testfehler ist der Teil, auf den es ankommt: Solange du ihn nicht auf Sentry ankommen siehst, weißt du nicht, ob es funktioniert. Dann schau in den Alerts von Sentry nach, ob es eine Regel für neue Fehler gibt.

Eine Seite zum Prüfen

Die Startseite lädt manchmal auch bei stehender Datenbank. Deshalb gebe ich dem Check eine eigene Seite:

Erstell eine Seite /health, die nur dann ok antwortet, wenn die App und die Datenbank funktionieren.

Wenn etwas nicht stimmt, muss die Seite mit einem Fehlercode antworten. Wenn sie eine normale Seite zeigt, auf der „Fehler“ steht, sieht der Check sie aufgehen und denkt, alles ist in Ordnung. Wenn Claude es noch nicht gemacht hat, schreibe ich dazu:

Wenn etwas nicht funktioniert, muss /health mit einem Fehlercode antworten, zum Beispiel 503, und darf keine internen Details zeigen, wie Passwörter, Datenbankadressen oder vollständige Fehlermeldungen.

Der Check alle 5 Minuten

1. Leg auf UptimeRobot einen neuen Monitor für [Adresse deiner App]/health an, mit einem Check alle 5 Minuten.
2. Als Benachrichtigung aktivierst du E-Mail und die Handy-App, in der du dich mit demselben Konto anmeldest.
3. Zum Testen trägst du kurz eine falsche Adresse in den Monitor ein und schaust, ob die Benachrichtigung ankommt. Dann setzt du wieder die richtige ein.

Sentry in Claude Code

Letzter Schritt: Du verbindest Sentry über einen MCP-Server mit Claude Code, damit Claude deine Fehler lesen kann. Start im Terminal diese Zeile, mit den Kurznamen deiner Organisation und deines Projekts auf Sentry anstelle von DEINE-ORG und DEIN-PROJEKT:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/DEINE-ORG/DEIN-PROJEKT

Beim ersten Mal lässt es dich im Browser bei Sentry anmelden; wenn das nicht passiert, tippst du in Claude Code /mcp und wählst sentry. Die Verbindung gilt nur in dem Projekt, in dem du die Zeile gestartet hast.

3. Wenn der Alarm losgeht

Wenn die Mail oder die Push-Nachricht kommt, öffne ich Claude Code im Projekt und füge den Alarm in diesen Prompt ein:

Ich habe diesen Alarm bekommen: [einfügen]. Lies den Fehler auf Sentry und die Logs und schreib mir in fünf Zeilen: was kaputt ist, seit wann, warum und welche Korrektur du vorschlägst. Fass in der Produktion nichts an, bis ich ok sage.

Fünf Zeilen, weil ich in dem Moment verstehen muss, nicht lesen. „Seit wann“ sagt mir, ob das letzte Deploy damit zu tun hat. Und der letzte Satz ist der wichtigste: Wenn die App down ist, will man sofort etwas reparieren, und eine falsche Korrektur in der Produktion kann mehr Schaden anrichten als der Fehler.

4. Wenn du es automatisch willst

Der nächste Schritt ist, den Alarm nicht einmal mehr einfügen zu müssen. Es gibt zwei Wege.

Mit offener Sitzung: /loop

Der einfache Weg: Du lässt eine Claude-Code-Sitzung offen, in der Sentry schon verbunden ist, und tippst:

/loop 5m schau auf Sentry nach, ob es neue Fehler gibt; wenn ja, lies den Stack Trace und schreib mir, was kaputt ist und wie du es beheben würdest.

Alle 5 Minuten schaut Claude auf Sentry und schreibt dir nur, wenn es neue Fehler findet: Das sind etwa 288 Durchläufe am Tag, also halt den Prompt kurz. Es funktioniert nur bei offener Sitzung und eingeschaltetem Computer, und nach 7 Tagen löscht sich der Loop selbst.

Bei ausgeschaltetem Computer: eine Routine mit API-Trigger

Eine Routine in der Cloud läuft auch bei ausgeschaltetem Computer, aber nach Zeitplan startet sie höchstens einmal pro Stunde. Für einen Alarm passt der API-Trigger besser: eine Webadresse, die die Routine startet, wenn du sie mit dem richtigen Token aufrufst.

Zwei Dinge vorab: Routinen brauchen einen kostenpflichtigen Claude-Plan und sind noch in der Vorschau, ihre Funktionsweise kann sich also ändern.

1. Klick auf claude.ai/code/routines auf New routine. Das Projekt muss auf GitHub liegen.
2. Füg Sentry unter claude.ai/customize/connectors als Konnektor hinzu: Die Verbindung, die du mit claude mcp add angelegt hast, liegt auf deinem Computer, und die Routine sieht sie nicht. Nimm die Konnektoren raus, die du nicht brauchst: Während der Routine nutzt Claude sie, ohne zu fragen.
3. Als Trigger wählst du API und speicherst. Er wird auf der Website hinzugefügt, nicht mit /schedule.
4. Kopier die Adresse der Routine, klick auf Generate token und kopier den Token sofort: Du siehst ihn nur einmal.
5. Richte in deinem Alarm-Tool einen Aufruf dieser Adresse mit dem Token ein, mit dem Text des Alarms im Feld text.

Die Grenze: Der API-Trigger braucht den Token und bestimmte Header, die du im Beispiel neben der Adresse findest. Kostenlose Alarm-Tools schaffen es eventuell nicht, ihn aufzurufen, also prüf deins vorher.

Der Text des Alarms kommt bei der Routine als Daten zum Lesen an, nicht als Befehl: Im Prompt musst du ihr selbst sagen, dass sie nachforschen soll. Ich nutze diesen:

Geh dem Alarm nach, der im Block routine-fire-payload beschrieben ist. Lies den Fehler auf Sentry, schau dir die letzten Commits an und schreib mir in fünf Zeilen: was kaputt ist, seit wann, warum und welche Korrektur du vorschlägst. Fass in der Produktion nichts an.

Die Routine läuft, ohne dich um Erlaubnis zu fragen, und das Ergebnis findest du in der Sitzung, die sie bei jedem Start anlegt. Deshalb bleibt „Fass in der Produktion nichts an“ drin: Sie untersucht und schlägt vor, du entscheidest.

Häufige Fehler

• Nur die Startseite prüfen: Sie kann auch bei stehender Datenbank laden, also lass /health prüfen.
• Eine /health-Seite, die auch bei einem Fehler eine normale Seite zeigt: Lass sie einen Fehlercode zurückgeben.
• Nichts testen: Lös den Testfehler und eine Test-Benachrichtigung aus und schau, ob sie bei dir ankommen.
• Claude während des Alarms in der Produktion reparieren lassen: Frag erst nach Diagnose und Vorschlag, dann entscheidest du.
• Davon ausgehen, dass die Routine das im Terminal verbundene Sentry sieht: Füg es als Konnektor auf claude.ai hinzu.

Checkliste

• Sentry in der App, mit dem DSN in einer Umgebungsvariable
• Testfehler auf Sentry angekommen
• Seite /health, die App und Datenbank prüft
• Monitor alle 5 Minuten auf /health, Benachrichtigungen per E-Mail und aufs Handy
• Sentry mit Claude Code verbunden, angemeldet
• Alarm-Prompt da gespeichert, wo du ihn sofort findest

Häufige Fragen