Mein System blieb um 1 Uhr nachts stehen. Erfahren habe ich es morgens, an einem verspäteten Bericht

Am 1. Juli 2026 hörte mein System nachts auf zu arbeiten und sagte kein Wort darüber. Gemerkt habe ich es morgens — nicht an einer Warnmeldung, sondern daran, dass der Tagesbericht verspätet ankam und kürzer war, als er sein sollte.

Ich schreibe das auf, weil es das Lehrreichste ist, was mir in diesem Projekt passiert ist, und weil der Mechanismus dahinter überall dort wiederkehrt, wo etwas in einer Warteschlange steht.

Was tatsächlich passiert ist

Bei mir laufen nachts mehrere Prozesse, die alle durch eine einzige Warteschlange zu einem lokalen Sprachmodell gehen: Marktanalyse, Compliance-Prüfung, Sicherheitsüberwachung. Alle betreten dasselbe Tor, einer nach dem anderen.

Nach einer Reihe ungewöhnlich langer Anfragen blieb der vermittelnde Prozess intern hängen. Entscheidend ist das Wort „intern": Er lief weiter. Er lauschte auf seinem Port, antwortete, dass er lebe, und hinterließ keinen einzigen Fehlereintrag. Er verarbeitete einfach keine neuen Anfragen mehr.

Das ist die schlimmste Art von Ausfall, die ich kenne. Ein Prozess, der abstürzt, hinterlässt eine Spur: einen Logeintrag, einen Neustart, eine Warnung. Ein Prozess, der stillsteht und „alles in Ordnung" antwortet, hinterlässt nichts — und das einzige Symptom ist, dass weiter hinten in der Kette etwas nicht rechtzeitig ankam.

Die Ursache

Zwei Dinge gleichzeitig, und erst zusammen ergeben sie einen Ausfall:

1. Eine tote, verwaiste Netzwerkverbindung. Die Gegenseite war verschwunden, der Socket blieb offen. Aus Sicht des Prozesses „lief" die Verbindung weiter, also wartete er auf eine Antwort, die nie kommen würde.
2. Überhaupt kein Zeitlimit auf dem kritischen Pfad. Das ist die eigentliche Ursache. Punkt eins ist etwas Alltägliches, das in Netzwerken täglich vorkommt — erst das fehlende Zeitlimit macht daraus den Stillstand des gesamten Systems.

Die Warteschlange ließ jeweils eine Aufgabe durch. Es genügte, dass die erste feststeckte, und alles dahinter stand.

Was ich nicht getan habe

Ich habe den Prozess nicht neu gestartet und keinen stündlichen Neustart eingerichtet. Das war der erste Gedanke und er ist falsch: Ein Neustart beseitigt das Symptom und sorgt dafür, dass die Ursache für immer im Code bleibt — nur sucht sie dann niemand mehr, weil „es läuft doch".

Die Reparatur

Drei Änderungen, alle im Code:

Freigabe der Warteschlange auf JEDEM Pfad. Vorher wurde die Warteschlange nach erfolgreicher Verarbeitung freigegeben. Jetzt wird sie immer freigegeben: bei Erfolg, bei Fehler und bei Zeitüberschreitung. Das ist die eine Änderung, die die ganze Klasse des Problems beseitigt und nicht nur diesen konkreten Fall. Wenn ich mir aus diesem Text einen Satz merken müsste, wäre es dieser: Das Aufräumen muss am Ausgang der Funktion hängen, nicht an ihrem glücklichen Ende.

Harte Zeitlimits auf jedem Schritt. Jeder Aufruf hat jetzt eine Obergrenze. Eine Aufgabe, die sie überschreitet, wird abgebrochen und protokolliert — statt endlos zu warten.

Eine E-Mail bei jeder Selbstheilung. Nicht bei einem Fehler — bei der Heilung. Das ist ein wichtiger Unterschied: Ein System, das sich still selbst repariert, ist ein System, das still vor dir verbirgt, dass etwas nicht stimmt. Ich will wissen, wie oft es sich aufgerichtet hat, denn eine steigende Zahl ist ein Signal, dass die Ursache an anderer Stelle zurückgekehrt ist.

Was in der Nacht vom 2. auf den 3. Juli geschah

Die Reparatur bekam einen Tag später ihre Praxisprobe. Die Warteschlange staute sich unter ungewöhnlich hoher Last — drei aufeinanderfolgende Aufgaben warteten immer länger (Zeiten in UTC):

2026-07-02 23:28 → wartete 51 Min. → Warteschlange automatisch freigegeben
2026-07-02 23:48 → wartete 65 Min. → Warteschlange automatisch freigegeben
2026-07-03 00:08 → wartete 78 Min. → Warteschlange automatisch freigegeben

Niemand ist aufgestanden. Das sind Nachtprozesse, eine Stunde Verzögerung bedeutet hier nichts — Bedeutung hat, dass morgens alles erledigt war und im Postfach drei Nachrichten lagen, die genau sagten, was passiert war.

In siebzehn Tagen Beobachtung habe ich 33 solcher Ereignisse gezählt. Ohne diese Änderung wäre jedes davon ein stiller Stillstand der ganzen Kette gewesen — bis zu dem Moment, in dem jemand einen fehlenden Bericht bemerkt.

Was daraus über meinen Server hinaus folgt

Drei Dinge, die ich in jedes weitere System mitnehme:

„Lebt" und „arbeitet" sind zwei verschiedene Fragen. Zu prüfen, ob ein Prozess antwortet, sagt nichts darüber, ob er irgendetwas tut. Seitdem messen meine Prüfungen Fortschritt, nicht Anwesenheit.

Stille ist keine gute Nachricht. Wenn das einzige Signal, dass ein System läuft, das Ausbleiben eines Alarms ist, dann hast du keine Überwachung — du hast Hoffnung. Derselbe Mechanismus hat mir später eine Sicherungskopie eingefangen, die sich seit 169 Tagen nicht verändert hatte: nicht weil etwas geschrien hätte, sondern weil der Tagesbericht das Alter der Kopie als Zahl nennt.

Repariere die Klasse, nicht den Fall. Ich hätte ein Zeitlimit an genau der Stelle einbauen können, an der es hängen blieb. Stattdessen bin ich alle Ausgangspfade dieser Funktion durchgegangen. Das hat einen halben Tag mehr gekostet und ist seitdem nicht wiedergekommen.

---

Die Zahlen in diesem Text stammen aus den Überwachungsdaten vom 1.–17. Juli 2026 und sind dieselben, die ich auf der Startseite zeige.