Die schlimmste Art, von einem Ausfall zu erfahren, ist die Nachricht eines Kunden mit dem Satz “geht das bei euch auch nicht?”. Nicht wegen des Ausfalls — der passiert jedem — sondern weil daraus hervorgeht, dass dein System dir nichts gesagt hat und du nicht weißt, seit wann es kaputt ist.
Für kleine Projekte braucht es dafür keinen großen Werkzeugkasten. Es braucht vier Signale und die Disziplin, bei Alarmen nicht abzustumpfen.
Die vier Signale, mit denen du anfängst
Ist es erreichbar? Der billigste und wirkungsvollste Check überhaupt: Ein externer Dienst ruft alle paar Minuten eine Adresse deiner Anwendung auf und meldet sich, wenn sie nicht antwortet. Wichtig ist das Wort “extern” — eine Überwachung, die auf demselben Server läuft wie die Anwendung, schweigt genau dann, wenn es darauf ankommt.
Bau dafür eine eigene Statusadresse, die nicht nur “der Webserver lebt” beantwortet, sondern kurz prüft, ob die Datenbankverbindung steht und die kritischen externen Dienste erreichbar sind. Eine Anwendung, die eine Startseite ausliefert, während der Bezahldienst nicht antwortet, ist für deine Nutzer trotzdem kaputt.
Gehen Fehler hoch? Ein Fehler-Tracking-Werkzeug, das nicht behandelte Ausnahmen mit Stacktrace, Anfrage-Kontext und Häufigkeit sammelt. Das ist der Unterschied zwischen “irgendwas stimmt nicht” und “seit dem Deploy um 14:20 schlägt diese Zeile bei jedem dritten Aufruf fehl”. Für die allermeisten kleinen Projekte reicht der kostenlose Tarif der gängigen Anbieter, und der Einbau dauert Minuten.
Laufen die Hintergrundjobs? Der am häufigsten übersehene Punkt. Cron-Jobs und Warteschlangen-Arbeiter scheitern still: Der Import läuft nicht mehr, die Rechnungsmails gehen nicht raus, das Backup schreibt in ein Verzeichnis, das es nicht mehr gibt — und niemand merkt es, weil nichts sichtbar kaputt ist. Die Lösung ist ein Totmannschalter: Der Job meldet nach erfolgreichem Durchlauf einen Ping an einen externen Dienst, und wenn dieser Ping ausbleibt, gibt es Alarm. Damit überwachst du Abwesenheit statt Anwesenheit — genau das, was hier gebraucht wird.
Läuft der Server voll? Speicherplatz, Arbeitsspeicher, ablaufende Zertifikate. Unspektakulär, aber die volle Festplatte ist nach wie vor eine der häufigsten Ursachen für nächtliche Ausfälle, meistens durch Logs oder Datenbank-Archive, die niemand rotiert.
Alarme, die man nicht ignoriert
Der eigentliche Fehler beim Monitoring ist nicht zu wenig Überwachung, sondern zu viel. Wer zwanzig Benachrichtigungen pro Tag bekommt, von denen neunzehn belanglos sind, hört nach einer Woche auf hinzuschauen — und übersieht dann die eine, die zählte.
Zwei Regeln helfen dagegen. Erstens: Ein Alarm darf nur ausgelöst werden, wenn du sofort etwas tun würdest. Alles andere ist ein Eintrag in einer Übersicht, die du morgens anschaust, keine Push-Nachricht um drei Uhr nachts. Zweitens: Jeder Alarm braucht eine Handlungsanweisung. Wenn du beim Lesen der Meldung nicht sofort weißt, was der erste Schritt ist, ist die Meldung nicht fertig.
Praktisch ergänzend: Setz für die wirklich kritischen Alarme einen Kanal ein, der dich auch dann erreicht, wenn du nicht am Rechner sitzt, und für alles andere einen, den du bewusst ignorieren darfst. Und richte kurze Verzögerungen ein, damit ein einzelner ausgefallener Aufruf nicht sofort alarmiert — die meisten kurzen Aussetzer erledigen sich innerhalb einer Minute von selbst.
Logs: Nützlich, wenn man sie wiederfindet
Logs sind nur so viel wert, wie du sie durchsuchen kannst. Eine Datei auf dem Server, in die alles hineinläuft, hilft dir beim Suchen genau so lange, wie das Projekt klein ist.
Der günstigste große Schritt ist strukturiertes Loggen: Jede Zeile ein JSON-Objekt mit Zeitstempel, Schweregrad, Nachricht und ein paar Kontextfeldern. Das ist unbequemer zu lesen und ungleich besser zu filtern. Besonders wertvoll ist eine mitgeführte Anfrage-Kennung, die durch alle Log-Zeilen einer Anfrage hindurchgereicht wird — damit rekonstruierst du einen konkreten Fehlerfall in Sekunden statt in Minuten.
Zwei Warnungen dazu. Erstens: Logs kosten Speicher, und ein zu gesprächiger Dienst hat schon manche Festplatte gefüllt. Rotation und Aufbewahrungsfristen gehören von Anfang an eingerichtet. Zweitens, und wichtiger: In Logs landet erschreckend oft, was dort nicht hingehört — vollständige Anfragekörper mit Passwörtern, Tokens in Kopfzeilen, personenbezogene Daten in Fehlermeldungen. Das ist nicht nur ein Sicherheits-, sondern auch ein Datenschutzproblem, besonders wenn die Logs bei einem externen Anbieter liegen. Filtere sensible Felder an der Quelle, nicht im Nachhinein.
Was du dir sparen kannst
Für ein Projekt mit überschaubarer Nutzerzahl brauchst du keine verteilte Ablaufverfolgung über mehrere Dienste, keine selbst betriebene Metrik-Datenbank mit Dashboards und keine Logsammlung, deren Betrieb aufwendiger ist als die Anwendung selbst. Diese Dinge lösen Probleme von Systemen mit vielen beteiligten Diensten und mehreren Teams.
Was sich dagegen schon bei einem einzigen Server lohnt, sind drei bis vier fachliche Kennzahlen — nicht technische. Wie viele Registrierungen gab es heute, wie viele Bestellungen, wie viele fehlgeschlagene Zahlungen. Diese Zahlen finden eine ganze Klasse von Fehlern, die technisch unsichtbar bleiben: Wenn das Anmeldeformular seit dem Deploy einen kaputten Validierungsfehler wirft, ist die Fehlerrate im Server-Log unauffällig, aber die Registrierungen fallen auf null. Kein technisches Signal hätte das gemeldet.
Die Faustregel
Fang mit Erreichbarkeitsprüfung, Fehler-Tracking und Totmannschaltern für deine Jobs an. Das sind drei Werkzeuge, meistens im kostenlosen Bereich, und der Einbau kostet dich einen Nachmittag. Alles Weitere baust du erst ein, wenn dich ein konkreter Vorfall gelehrt hat, was dir gefehlt hat — und nach jedem Vorfall solltest du genau diese Frage stellen: Welches Signal hätte mich zwanzig Minuten früher informiert? Dann bau genau dieses eine ein.
Monitoring, das aus echten Vorfällen gewachsen ist, passt zu deinem System. Monitoring nach Vorlage überwacht das System von jemand anderem.
Wenn du wissen willst, womit andere kleine Projekte überwachen: Im Discord der Community werden solche Setups regelmäßig geteilt.