Merken, wenn etwas kaputt ist

Drei Fragen nach dem Start

Solange du selbst der einzige Nutzer bist, merkst du jeden Fehler sofort. Nach dem Start sind andere die Nutzer, und du sitzt nicht daneben. Von da an brauchst du Antworten auf drei Fragen, ohne nachsehen zu müssen: Läuft es? Was kostet es? Wird es genutzt?

Dafür braucht es kein Betriebsteam und kein großes Budget. Die Werkzeuge in diesem Teil der Serie sind frei verfügbar oder lassen sich mit dem Agenten selbst bauen. Angaben zu einzelnen Werkzeugen haben den Stand 13.10.2026 und stammen aus deren eigener Darstellung. Preise nennen wir nicht.

Eine Regel gilt für alles Folgende: Was überwacht, darf nicht dort laufen, wo das Überwachte läuft. Ein Wächter auf demselben Server fällt mit dem Server aus und meldet nichts.

Von außen nachsehen

Die einfachste Überwachung ruft die Anwendung in festen Abständen von außen auf und meldet sich, wenn keine Antwort kommt. Dafür gibt es gehostete Dienste und freie Software zum Selbstbetrieb. Uptime Kuma etwa ist ein frei verfügbares Werkzeug zum Selbstbetrieb, das genau das tut und Meldungen über E-Mail und viele Messenger verschicken kann. Betreibst du es selbst, dann auf einem anderen Server und am besten bei einem anderen Anbieter als die Anwendung.

Damit so eine Prüfung mehr sagt als "die Startseite lädt", braucht die Anwendung eine Adresse, die ihren Zustand ehrlich meldet:

Das Einrichten der Überwachung selbst machst du von Hand, weil daran ein Konto und dein Telefon hängen:

1. Leg die Prüfung für die Zustandsadresse an, mit einem Abstand von einer bis fünf Minuten.
2. Leg eine zweite Prüfung für den wichtigsten Ablauf an, etwa die Anmeldeseite.
3. Trag als Empfänger einen Kanal ein, der dich wirklich erreicht, also eine Benachrichtigung aufs Telefon und nicht nur eine E-Mail.
4. Lös den Alarm einmal absichtlich aus, indem du die Testumgebung stoppst oder die Adresse kurz falsch einträgst.

Lass den vierten Schritt nicht aus. Ein Alarm, der nie geklingelt hat, ist eine Vermutung.

Fehler, die niemand meldet

Viele Fehler legen nicht die ganze Anwendung lahm. Ein Nutzer klickt, es passiert nichts, und er geht. Davon erfährst du nur, wenn die Anwendung ihre Fehler selbst meldet. Das leisten Werkzeuge zur Fehlererfassung: Sie sammeln jeden Fehler mit Zeitpunkt, Stelle im Code und Häufigkeit an einem Ort.

Sentry ist ein bekannter Dienst dafür, für Web-Anwendungen genauso wie für mobile Apps. Offizielle Bibliotheken gibt es unter anderem für JavaScript, Android, Apple-Plattformen und React Native. In einer Web-App meldet Sentry den Fehler, der im Browser eines Nutzers auftritt, in einer mobilen App den Fehler auf einem Gerät, das du nie in der Hand hattest. Der kostenlose Developer-Plan gilt für eine Person und bringt ein Kontingent von 5.000 Fehlern mit, der Team-Plan beginnt bei 26 Dollar im Monat (Stand 13.10.2026). Beim Anlegen der Organisation wählst du, ob die Daten in den USA oder in Frankfurt gespeichert werden. Diese Wahl lässt sich später nicht mehr ändern.

Die Software lässt sich auch selbst betreiben, laut Sentry als minimales Setup ohne Garantien und ohne eigenen Support. GlitchTip ist eine Open-Source-Alternative, die nach eigener Angabe mit den Client-Bibliotheken von Sentry zusammenarbeitet und einfacher zu betreiben sein will. Auch hier gilt: gehostet oder auf einem eigenen, getrennten Server.

Die erste Regel im Prompt hat einen Grund. Ein Fehlerbericht, der die Eingabe des Nutzers enthält, schickt personenbezogene Daten an einen weiteren Dienst. Für einen gehosteten Anbieter brauchst du dann einen Vertrag zur Auftragsverarbeitung, und der Dienst gehört in die Datenschutzerklärung.

Aufgaben im Hintergrund

Manche Fehler bestehen darin, dass etwas nicht passiert. Das nächtliche Backup läuft nicht, die Rechnungen werden nicht verschickt, der Abgleich mit dem Zahlungsanbieter bleibt hängen. Kein Nutzer sieht das, und eine Prüfung von außen auch nicht.

Dagegen hilft ein umgekehrter Alarm: Die Aufgabe meldet sich nach jedem erfolgreichen Lauf bei einem Wächter, und der schlägt an, wenn die Meldung ausbleibt. Healthchecks.io arbeitet so. Man erzeugt für jede Aufgabe eine eigene Adresse, die Aufgabe ruft sie am Ende auf, und bleibt der Aufruf aus, kommt eine Benachrichtigung. Die Software steht unter einer BSD-Lizenz und lässt sich auch selbst betreiben.

Das wichtigste Beispiel ist das Backup aus dem Serienteil Die Datenbank hinter dem Prototyp absichern. Ein Backup, das seit drei Wochen nicht mehr läuft, fällt sonst erst auf, wenn du es brauchst.

Wenige Messwerte, richtig gelesen

Wer mehr als "erreichbar oder nicht" wissen will, kommt mit vier Größen weit. Googles Buch über den Betrieb großer Systeme, das SRE-Buch, nennt sie die vier goldenen Signale: Antwortzeit, Last, Fehler und Auslastung. Dazu der Satz: "If you can only measure four metrics of your user-facing system, focus on these four."

Für Nicht-Techniker übersetzt: wie lange Nutzer warten, wie viele gerade da sind, wie oft etwas schiefgeht und wie nah das System an seiner Grenze ist.

Bei der Antwortzeit lohnt ein genauer Blick auf die Darstellung. Der Durchschnitt versteckt die schlechten Fälle. Das zugehörige Arbeitsbuch empfiehlt deshalb Perzentile: Sie zeigen, ob die Hälfte, fünf Prozent oder ein Prozent der Anfragen zu langsam sind, wo der Mittelwert nur sagt, dass es langsamer geworden ist. Wenn jede zwanzigste Anfrage zehn Sekunden braucht, ist das für die Betroffenen ein kaputtes Produkt, im Durchschnitt aber kaum zu sehen.

Viele Plattformen zeigen solche Werte von sich aus an. Sieh dort zuerst nach, bevor du etwas aufbaust. Wächst die Anwendung, gibt es dafür etablierte freie Bausteine: Prometheus sammelt Messwerte und löst Alarme aus, und OpenTelemetry ist ein herstellerunabhängiger Standard, mit dem die Anwendung ihre Daten so ausgibt, dass du das Auswertungswerkzeug später wechseln kannst. Am ersten Tag ist beides mehr, als du brauchst.

Alarme, die jemand ernst nimmt

Ein Alarm ist nur so gut wie die Reaktion darauf. Das SRE-Arbeitsbuch fasst die Regel knapp: "Alert on conditions that require attention." Alles andere gehört in eine Übersicht, die man sich ansieht, wenn man Zeit hat.

Für den Anfang reichen wenige Alarme, bei denen sofort jemand handeln muss:

• Die Anwendung ist von außen nicht erreichbar.
• Die Fehlerrate liegt deutlich über dem Üblichen.
• Eine Hintergrundaufgabe hat sich nicht gemeldet.
• Die Kosten des Tages liegen deutlich über dem Üblichen.

Jeder weitere Alarm muss sich die Frage gefallen lassen, was der Empfänger nachts um drei damit tun soll. Gibt es darauf keine Antwort, ist es eine Zeile im Wochenbericht.

Als Kanal taugt, was aufs Telefon kommt. ntfy zum Beispiel ist freie Software, die Benachrichtigungen über einen einfachen HTTP-Aufruf aufs Telefon schickt. Viele Überwachungswerkzeuge können auch direkt in einen Messenger melden.

Zu jedem Alarm gehört ein Name. Wer bekommt ihn, wer vertritt, und was ist der erste Handgriff? Schreib das in eine Datei im Repository. Dazu kommt ein Punkt, den OWASP unter den Sicherheitsrisiken führt: Ohne Protokollierung und Alarmierung lassen sich Angriffe weder erkennen noch schnell beantworten. Fehlgeschlagene Anmeldungen in großer Zahl oder abgelehnte Zugriffe auf fremde Daten gehören deshalb ins Protokoll.

Was kostet es

Die Kosten pro Tag sind ein Betriebswert wie die Fehlerrate. Wie du sie je Kunde erfasst und begrenzt, steht im Serienteil Was eine KI-Funktion pro Kunde kostet. Für den Betrieb zählt daraus eines: Der Tageswert gehört in dieselbe Übersicht wie die anderen Werte und bekommt einen Alarm.

Der selbst gebaute Bericht zur Nutzung

Ein Produkt kann technisch einwandfrei laufen, ohne dass jemand es benutzt. Das zeigt keine Überwachung. Dafür brauchst du zwei oder drei Kennzahlen, die zum Zweck des Produkts passen. Als Ausgangspunkt eignen sich diese Fragen:

• Wie viele Nutzer waren in dieser Woche aktiv?
• Wie viele haben den Kernablauf bis zum Ende durchlaufen, also das getan, wofür das Produkt da ist?
• Wie viele von denen, die vor vier Wochen angefangen haben, sind noch da?
• Bei KI-Funktionen: Wie oft wird ein Ergebnis übernommen, und wie oft verworfen oder neu angefordert?

Die Antworten liegen oft schon in deiner eigenen Datenbank. Statt ein Analysewerkzeug einzubinden, kannst du dir den Bericht bauen lassen. Hier kann Selbstbauen die bessere Wahl sein: Die Daten verlassen dein System nicht, und der Bericht zeigt genau deine Fragen.

Der letzte Satz im Prompt ist wichtig, weil oft genau die Angabe fehlt, an der sich ein Abbruch erkennen ließe. Lieber früh ein Ereignis mehr speichern als nach drei Monaten feststellen, dass die Frage nicht zu beantworten ist.

Wer zusätzlich wissen will, woher Besucher kommen und welche Seiten sie ansehen, braucht eine Webanalyse. Für den DACH-Raum zählt dabei, wo die Daten liegen und ob ein Einwilligungsbanner nötig wird. Plausible wirbt damit, in der EU gebaut und gehostet zu sein und ohne Cookie-Banner auszukommen. Die Community Edition steht unter der AGPL und lässt sich selbst betreiben. PostHog, ein Werkzeug für Produktanalyse, bietet eine Cloud-Variante mit Servern in Frankfurt. Ob eine Einwilligung nötig ist, hängt von der konkreten Einrichtung ab und gehört mit dem Datenschutz geklärt.

Wer zuständig ist

Beim eigenen Produkt bist du es, und die Frage ist nur, wer dich vertritt.

Beim Kundenauftrag muss vor dem Start feststehen, wer die Alarme bekommt und wer handelt. Bleibt der Betrieb beim Dienstleister, gehört in den Vertrag, was "verfügbar" heißt und wie schnell reagiert wird. Das SRE-Buch trennt dafür drei Begriffe, die im Alltag unter "SLA" durcheinandergehen: den Messwert, etwa den Anteil erfolgreicher Anfragen, das Ziel für diesen Wert und die Vereinbarung darüber, was bei Verfehlen passiert. Leg mit dem Kunden zuerst den Messwert fest. Über eine Prozentzahl lässt sich nicht sinnvoll streiten, solange offen ist, was gemessen wird. Übernimmt der Kunde den Betrieb, übergibst du die Überwachung mit: die Konten, die Alarme und die Datei mit den Zuständigkeiten.

Beim internen Werkzeug fehlt die zuständige Person am ehesten, weil das Werkzeug nebenher entstanden ist. Trag einen Namen ein und sprich mit der IT, bevor der erste Ausfall die Frage stellt.

Womit du heute anfängst

Mit der Prüfung von außen und einem Alarm aufs Telefon, einmal absichtlich ausgelöst. Das ist in einer Stunde erledigt.

Als Zweites kommt der Wächter für das Backup, als Drittes die Fehlererfassung. Den Wochenbericht lässt du bauen, sobald die ersten echten Nutzer da sind. Mit Testdaten sagt er nichts.