Wenn ein Service, auf den Sie angewiesen sind, abbaut, landen Fehlerberichte bei Ihnen

Kurz nach Mitternacht am 27. August 2026 stieg die Temperatur im Hauptrechenzentrumraum von Proton in Frankfurt von 21,8 °C auf 51,9 °C in unter dreißig Minuten an. Ein Kühlsystem war ausgefallen, und Netzwerkausrüstung, die 105 °C erreichte, schaltete sich selbst in einen Schutzmodus, der sie deaktivierte, bis ein kalter Neustart erfolgte. Proton war für etwa zwei Stunden nicht erreichbar.

Was es wert ist zu lesen, ist nicht, dass es passiert ist – jede Infrastruktur fällt irgendwann aus – sondern der Incident-Report, den Proton später veröffentlichte, der auf eine Weise spezifisch ist, wie die meisten es nicht sind. Der Bericht nennt die Ursache: ein Austausch des Luftfilters an den redundanten Luftkompressoren, durchgeführt vom Rechenzentrumsbetreiber „mitten in der Nacht, ohne vorherige Benachrichtigung”, der „versäumte es auch, den Kühlausfall zu kommunizieren, als er passierte”. Er erklärt, warum die Wiederherstellung langsam statt sofort ablief: Das Team entschied sich, die Hardware zu retten, anstatt den Service schnell wiederherzustellen, weil der Austausch schwierig ist „mit dem anhaltenden KI-Boom”, der die Lieferung belastend macht. Ein Postmortem, das so spezifisch ist, ist ein Gefallen für alle, die etwas betreiben, und es lohnt sich, das zu sagen.

Aber es gibt eine zweite Sache darin, die die Aufmerksamkeit von jedem wert ist, der Fehlerberichte erhält, und es ist leicht zu übersehen. Das benutzerseitige Symptom war nicht eine Meldung „Proton ist nicht erreichbar”. Es war dies, in ihren Worten: „Keine E-Mails gingen verloren, aber die E-Mail-Zustellung in beide Richtungen wurde verzögert.”

Der Ausfall, der sich nicht selbst ankündigt

Ein vollständiger Ausfall ist der einfache Fall. Die Website gibt einen 503 zurück, die Seite lädt nicht, jeder versteht innerhalb einer Minute, dass das Problem nicht bei ihnen liegt.

Eine Leistungsminderung ist der schwierige Fall. Etwas, auf das Sie angewiesen sind, wird langsam, oder lässt eine Anfrage von zwanzig fallen, oder verzögert eine Lieferung – und es bleibt so lange erreichbar, dass nichts den Fehler ankündigt. Das Symptom zeigt sich nicht dort, wo der Fehler ist. Es zeigt sich im nächsten System, das sehr oft Ihres ist, erlebt von einem Benutzer, der keinen Grund hat, einen Rechenzentrumsausfall in Frankfurt zu vermuten, und jeden Grund hat, die App vor ihm zu verdächtigen.

Der Bericht, den Sie erhalten, sagt also nicht „mein Anbieter hat einen Kühlungsvorfall”. Er sagt „Ihre App ist langsam”, oder „sie hat nichts gesendet”, oder „es funktionierte heute Morgen und jetzt nicht mehr” – und Sie verbringen die erste Stunde mit der Suche an dem einen Ort, an dem das Problem nicht ist, weil das der Ort ist, auf den die Person hingewiesen hat.

Ihren Ausfall von Ihrem Fehler unterscheiden, während es passiert

Der Unterschied ist in der Regel in Minuten sichtbar, wenn Sie wissen, worauf Sie schauen müssen, und dies ist ungefähr die Reihenfolge.

Betrifft es nur die eine Abhängigkeit? Eine Leistungsminderung beim Upstream zeigt sich in einem Muster: die Anfragen, die diesen Service betreffen, sind langsam oder schlagen fehl, und alles andere auf der Seite funktioniert einwandfrei. Ein Fehler Ihrerseits ist selten so ordentlich. Öffnen Sie den Netzwerk-Reiter und beobachten Sie, welche Anfragen rot oder langsam sind. Wenn sie alle zu einem Host gehen und nichts anderes betroffen ist, handelt es sich um ein Problem bei Ihrem Anbieter.

Welche Form hat der Fehler? Ein 504 Gateway Timeout ist ein Server vor einem anderen Server, der nie geantwortet hat – ein typischer Fingerabdruck eines Upstream, der erreichbar ist, aber nicht antwortet, was genau wie eine Leistungsminderung von außen aussieht. Eine Anfrage, die sich aufhängt und dann ausläuft, anstatt einen Fehler zurückzugeben, den Ihr Code erzeugt hätte, deutet ebenfalls darauf hin.

Bestätigt die Statusseite des Anbieters das? Sie hinkt dem Incident oft um mehrere Minuten hinterher, daher beweist eine grüne Statusseite früh nichts – der Fehler erreichte Sie, bevor er dem Dashboard erreichte. Aber sobald sie sich ändert, ist die Frage geklärt. Überprüfen Sie sie, und vergleichen Sie die Zeitstempel mit dem Zeitpunkt, an dem Ihre Berichte begannen.

Hat sich etwas bei Ihnen geändert? Wenn Sie nicht bereitgestellt haben und der Code, der jetzt fehlschlägt, vor einer Stunde funktionierte und nicht berührt wurde, ist das, was sich geändert hat, wahrscheinlicher auf der anderen Seite der Verbindung als in einer Datei, die Sie sehen können.

Die vollständige Version davon – die Begründung für jeden Check und wie man unter Druck vorgeht – ist in Ist es Ihr Fehler oder ein Ausfall.

Was man erfasst, um später nicht darüber zu streiten

Das Problem bei einer Leistungsminderung beim Upstream ist, dass sie vorbei ist, bis jemand Sie bittet zu beweisen, dass es nicht Ihre Schuld war. Der Anbieter erholt sich, die Statusseite wird grün, das Postmortem erscheint eine Woche später, und alles, was Sie haben, ist die Erinnerung an einen schlechten Nachmittag und keine Aufzeichnung.

Erfassen Sie also, während es passiert, die Beweise, die das Symptom mit dem Upstream verbinden: die fehlgeschlagenen Anfragen mit ihren Statuscodes und Zeitpunkten, die Zeitstempel, die Antwort, die der Upstream tatsächlich zurückgab. Das ist der Unterschied zwischen „wir denken, es war unser Anbieter” und einem Bericht mit den 504-Fehlern und den Lieferverzögerungen neben der Incident-Timeline des Anbieters selbst. Eine ist ein Streit, die andere ist geklärt.

Das Netzwerkprotokoll, das es erfasst, ist die Aufzeichnung davon, welche Anfragen genau fehlgeschlagen sind und wie lange sie gedauert haben, gespeichert in dem Moment, in dem der Fehler auftrat, anstatt danach rekonstruiert zu werden. Wenn die Frage ist, ob der Fehler bei Ihnen oder beim Anbieter lag, antwortet dieses Protokoll darauf – und es verschwindet nicht, wenn sich der Anbieter erholt hat.