Vorlage für eine Ausfallbenachrichtigung

Eine Ausfallbenachrichtigung teilt Kunden mit, dass ein Dienst, auf den sie angewiesen sind, gestört ist, was betroffen ist und was Ihr Team dagegen unternimmt. Sie hat meist zwei Formen: eine Meldung auf Ihrer Statusseite, die im Verlauf des Vorfalls aktualisiert wird, und eine E-Mail an die betroffenen Kunden.

Sie ist eine öffentliche Nachricht. Interne Details wie die vermutete Änderung, wer Bereitschaft hat oder welche Theorie das Team gerade prüft, bleiben im Incident-Kanal und im Vorfallsbericht. Die Benachrichtigung enthält nur, was Kunden brauchen, um über ihre nächsten Schritte zu entscheiden.

Dieselben Nachrichten werden oft auch Vorfallskommunikation genannt: die Folge von Updates, die ein Vorfall von der ersten Bestätigung bis zur Behebung hervorbringt.

Auf Statusseiten durchläuft ein Vorfall vier Phasen. Jede sagt Kunden etwas anderes, und jedes Update ersetzt das vorherige.

Nicht jeder Vorfall durchläuft alle vier. Nach einem schnellen Rollback kann es direkt von „Wird untersucht“ zu „Wird überwacht“ gehen. Lassen Sie lieber eine Phase aus, als ein Update zu veröffentlichen, das nichts Neues sagt.

Der Dienststatus gibt an, wie viel des Dienstes Kunden nutzen können. Er entspricht dem Komponentenstatus auf Ihrer Statusseite, sodass Meldung und Seite übereinstimmen.

• Beeinträchtigt. Der Dienst funktioniert, aber schlecht: langsame Antworten, sporadische Fehler, verzögerte Verarbeitung.
• Teilausfall. Ein Teil des Dienstes funktioniert für einige Nutzer nicht: eine Funktion, eine Region oder eine Gruppe von Konten.
• Nicht verfügbar. Der Dienst kann überhaupt nicht genutzt werden.

Beschreiben Sie die Auswirkungen mit dem Dienststatus, nicht mit Ihrem internen Schweregrad. Am Schweregrad entscheidet Ihr Team, wie dringend es reagiert und wer alarmiert wird. Einem Kunden sagt „SEV-2“ nichts, und es kann in die Irre führen: Ein Vorfall, der für einen großen Kunden kritisch ist, kann für alle anderen ein Teilausfall sein. Der Dienststatus beschreibt, was Kunden tatsächlich erleben.

Der Dienststatus kann sich während eines Vorfalls ändern. Weitet sich ein Teilausfall aus, setzen Sie die Meldung auf „Nicht verfügbar“, statt den ursprünglichen Status stehen zu lassen.

Veröffentlichen Sie die erste Meldung, sobald Auswirkungen für Kunden bestätigt sind, noch bevor Sie die Ursache kennen. Dafür ist der Status „Wird untersucht“ da. Kunden, die Fehler sehen, während die Statusseite durchgehend grün ist, gehen davon aus, dass Sie nichts davon wissen, und eröffnen Support-Tickets, um es Ihnen mitzuteilen.

Aktualisieren Sie die Meldung jedes Mal, wenn sich der Vorfallstatus oder der Dienststatus ändert. Veröffentlichen Sie während einer langen Untersuchung auch dann ein Update, wenn sich nichts geändert hat, damit die Seite nicht verlassen wirkt.

Schreiben Sie den betroffenen Kunden per E-Mail, wenn der Vorfall beginnt und wenn er behoben ist. Ob Sie auch bei „Identifiziert“ und „Wird überwacht“ eine E-Mail senden, hängt davon ab, wie lange der Vorfall dauert; bei einem kurzen Vorfall deckt die Statusseite die Zwischenschritte ab.

Meldung auf der Statusseite

Eine Meldung behält während ihrer gesamten Lebensdauer denselben Titel. Beschreiben Sie das Symptom, nicht die Ursache: „Erhöhte API-Fehlerraten“, nicht „Datenbank-Verbindungspool erschöpft“. Lassen Sie Komponentennamen weg, wenn sich die Liste ändern kann, und lassen Sie den Schweregrad weg.

Neben dem Titel: der Vorfallstatus, der Dienststatus, die betroffenen Komponenten und der Beginn der Auswirkungen. Kunden gleichen den Vorfall anhand der Startzeit mit Problemen ab, die sie selbst bemerkt haben, geben Sie also immer die Zeitzone an. Die Vorlage setzt die aktuelle Uhrzeit in Ihrer Zeitzone ein.

Das Update selbst umfasst ein bis zwei Sätze: was betroffen ist und was Sie unternehmen. Spekulieren Sie nicht über die Ursache, und versprechen Sie keinen Zeitpunkt für die Lösung, den Sie nicht einhalten können.

Kunden-E-Mail

Die Betreffzeile transportiert die Nachricht für alle, die die E-Mail nicht öffnen: [Vorfallstatus] Titel der Meldung – betroffen: Komponenten → Dienststatus. Zum Beispiel „[Wird untersucht] Erhöhte API-Fehlerraten – betroffen: API → Teilausfall“. Kunden können danach filtern, und eine spätere E-Mail mit „[Behoben]“, ohne Dienststatus, schließt den Verlauf ab.

Der Text wiederholt das Update von der Statusseite wörtlich, damit die Fakten auf allen Kanälen gleich sind, und verlinkt für weitere Updates auf die Statusseite. Sobald der Vorfall behoben ist, tritt an die Stelle des Links das Angebot, bei Fragen auf die E-Mail zu antworten.

Die folgenden Beispiele führen den Vorfall INC-2026-017 aus den Vorlagen für den Vorfallsbericht und das Postmortem fort. Etwa 18 % der API-Anfragen schlugen 28 Minuten lang fehl, während Dashboards und Statusseite weiter funktionierten: ein Teilausfall.

Titel der Meldung: Erhöhte API-Fehlerraten Betroffene Komponenten: API Beginn: 2026-09-03 14:03 UTC

Derselbe Vorfall als „Beeinträchtigt“

Hätten die Abfragen die API nur verlangsamt, statt Anfragen fehlschlagen zu lassen, wäre der Dienststatus „Beeinträchtigt“, und das erste Update würde lauten:

Wir untersuchen Berichte über Probleme, die einige Funktionen betreffen. Es kann zu leichten Verzögerungen oder sporadischen Fehlern kommen.

Kunden-E-Mail

Betreff: [Wird untersucht] Erhöhte API-Fehlerraten – betroffen: API → Teilausfall

Hallo Alex,

Wir untersuchen einen Teilausfall. Einige Funktionen sind derzeit für einige Nutzer nicht verfügbar.

Den weiteren Verlauf können Sie auf unserer Statusseite verfolgen: status.example.com

Wir entschuldigen uns für die Störung.

Ihr Example-Team

Meldung und E-Mail werden in Minuten geschrieben, für Kunden, während der Vorfall noch läuft. Das Postmortem folgt später und erklärt. Der Vorfallsbericht ist die interne Dokumentation hinter allen dreien.

• Beginnen Sie mit den Auswirkungen, nicht mit der Ursache. Kunden müssen wissen, was sie nicht tun können. Die Ursache kann bis zum Postmortem warten.
• Schreiben Sie verständlich. Schreiben Sie „einige Nutzer können sich nicht anmelden“, nicht „erhöhte 5xx-Raten im Auth-Service“.
• Spekulieren Sie nicht. Sagen Sie erst, dass Sie die Ursache identifiziert haben, wenn das zutrifft. Eine falsche Vermutung öffentlich zu korrigieren kostet mehr Vertrauen als zu warten.
• Beschreiben Sie Auswirkungen als Dienststatus, und behalten Sie Schweregrade intern. Beeinträchtigt, Teilausfall oder nicht verfügbar sagt Kunden, was sie erleben; SEV-Stufen tun das nicht.
• Halten Sie die Fakten auf allen Kanälen gleich. Statusseite, E-Mail und das, was der Support Kunden sagt, sollten übereinstimmen.
• Versprechen Sie keinen Zeitpunkt für die Lösung, den Sie nicht einhalten können. Eine verfehlte Schätzung schadet mehr als gar keine.
• Schließen Sie jeden Vorfall ab. Eine Meldung, die stundenlang auf „Wird überwacht“ steht, lässt Kunden rätseln, ob der Vorfall vorbei ist.

Was sollte eine Vorlage für die Vorfallskommunikation enthalten?

Jedes Update sollte sagen, was betroffen ist, wie stark (beeinträchtigt, Teilausfall oder nicht verfügbar) und was Ihr Team unternimmt, dazu, wann das Problem begonnen hat. Beschränken Sie jedes Update auf ein bis zwei Sätze, und heben Sie Ursache und interne Details für das Postmortem auf.

Wie oft sollten Sie Kunden während eines Ausfalls informieren?

Immer dann, wenn sich der Vorfallstatus oder der Dienststatus ändert. Veröffentlichen Sie während einer langen Untersuchung außerdem in regelmäßigen Abständen ein Update, etwa alle 30 oder 60 Minuten, auch wenn sich nichts geändert hat, damit Kunden wissen, dass der Vorfall nicht vergessen wurde.

Was ist der Unterschied zwischen beeinträchtigter Leistung und einem Teilausfall?

Bei beeinträchtigter Leistung funktioniert der Dienst für alle weiterhin, aber langsam oder mit sporadischen Fehlern. Bei einem Teilausfall funktioniert ein Teil des Dienstes für einige Nutzer überhaupt nicht, etwa eine Funktion, eine Region oder eine Gruppe von Konten.

Sollten Sie sich in einer Ausfallbenachrichtigung entschuldigen?

Ja, in der Kunden-E-Mail. Ein Satz wie „Wir entschuldigen uns für die Störung“ erkennt die Auswirkungen an, ohne die Nachricht zu einer Stellungnahme zu machen. Updates auf der Statusseite können sachlich bleiben.

Legen Sie vor dem nächsten Vorfall fest, wer die Meldung veröffentlicht, wer die E-Mail versendet und welche Kunden sie erhalten. Formulieren Sie die Texte im Voraus, wie es diese Vorlage tut, damit das erste Update innerhalb von Minuten veröffentlicht wird statt nach einer Diskussion über die Wortwahl. Halten Sie diese Entscheidungen in Ihrem Incident-Response-Plan fest.

Konsequent umgesetzt, reduzieren Ausfallbenachrichtigungen die „Ist es down?“-Support-Tickets und halten Kunden auch bei den Vorfällen auf dem Laufenden, die Sie nicht verhindern können.

Mehr zur Vorfallskommunikation im StatusPal-Blog (auf Englisch):

• All About Incident Communication: warum vorformulierte Vorlagen Nachrichten schnell und einheitlich halten, und die Schritte Erstkontakt, Statusupdate und Behebung, denen diese Vorlage folgt.
• How To Create an Incident Communication Plan: wen Sie informieren, über welche Kanäle, und warum regelmäßige Updates auch dann wichtig sind, wenn sich nichts geändert hat.
• Key Learnings from the Facebook Status Page: was schiefgeht, wenn eine Statusseite während eines Ausfalls „fehlerfrei“ anzeigt oder nicht angibt, wann der Vorfall begonnen hat.