So erstellst du eine Status Page

Eine Statusseite lohnt sich nur, wenn sie sich während eines Incidents selbst aktualisiert und Kunden sie finden können, wenn sie sie brauchen. Diese Schritte bauen von Anfang an eine Seite, die von echten Monitoren gesteuert wird und genug menschlichen Kontext liefert, um Support-Rauschen zu reduzieren.

1. 1

   Entscheide, welche Komponenten sichtbar sein sollen

   Liste die Teile deines Produkts auf, die ein Kunde separat erkennen und wichtig finden würde: die Hauptseite oder App, die API, wenn andere sie integrieren, Checkout oder Billing, wenn sie unabhängig ausfallen können, und jeden kritischen Hintergrunddienst, den Kunden bemerken, wenn er stoppt. Halte die Liste kurz und sinnvoll; drei bis sechs erkennbare Komponenten sind besser als zwanzig interne Labels, die außerhalb deines Teams niemand versteht.

2. 2

   Verbinde jede Komponente mit einem echten Monitor

   Verbinde jede Komponente auf der Seite mit dem Monitor, der sie bereits prüft: derselben Outside-in-Prüfung oder demselben Heartbeat, der deine Website im Alltag überwacht. Genau dadurch aktualisiert sich die Seite selbst: Die Komponente wird rot, wenn die zugrunde liegende Prüfung fehlschlägt, und wieder grün, wenn sie sich erholt, ohne manuellen Schritt dazwischen. Wenn hinter einer Komponente kein Monitor steht, füge einen hinzu oder lass sie von der öffentlichen Seite weg.

3. 3

   Veröffentlichen und dort verlinken, wo Menschen suchen

   Platziere den Link zur Statusseite dort, wo er während eines Incidents tatsächlich gefunden wird: Website-Footer, Docs, Support-Autoreply, Onboarding-E-Mails und API-Dokumentation sind typische Stellen. Eine technisch live geschaltete, aber nirgends verlinkte Statusseite spart keine Support-Tickets. Wenn Kunden Verträge oder SLAs haben, stelle sicher, dass diese Seite der Ort ist, auf den du während eines Ausfalls verweist.

Nachdem sie live ist

Veröffentliche während eines echten Incidents ein kurzes Update, sobald du weißt, dass etwas nicht stimmt, auch bevor du die Ursache kennst: „Wir wissen Bescheid und untersuchen es“ ist besser als Stille. Aktualisiere erneut, wenn du mehr Informationen hast, und poste eine Abschlussnotiz, wenn es behoben ist. Der automatische Komponentenstatus beantwortet „up oder down“; eine kurze menschliche Notiz erklärt Auswirkungen, Umfang, Workaround und Zeitpunkt des nächsten Updates. Beides zählt während eines Incidents.

Was du als Nächstes hinzufügen solltest

Sobald die Seite live ist und korrekt mit echten Monitoren verdrahtet wurde, ergänze die Elemente, die wiederholte Fragen reduzieren: ein Uptime-History-Badge, RSS- oder E-Mail-Abos und eine kurze Incident-Vorlage, die dein Team unter Druck wiederverwenden kann. Wenn die zugrunde liegenden Monitore TLS- oder Domain-Ablaufprüfungen enthalten, entscheide, ob diese kundensichtbare Komponenten verdienen oder besser als Teil des Hauptseitenstatus dargestellt werden: Ein bald ablaufendes Zertifikat ist ein echtes Risiko, braucht aber vielleicht keine eigene öffentliche Zeile.

Häufige Fehler vermeiden

Jede interne Komponente auflisten. Eine Seite mit einem Dutzend Komponenten, die kein Kunde erkennt, ist auf einen Blick schwerer zu erfassen als eine mit drei oder vier Dingen, die ihnen wirklich wichtig sind. Hebe die Detailaufschlüsselung für eine interne Ansicht auf, wenn dein Team eine möchte.

Sie mit nichts verbinden. Eine Statusseite ohne echten Monitor ist nur eine statische Seite, an deren Aktualisierung jemand denken muss, und genau das scheitert in dem Moment, in dem alle am beschäftigtsten sind. Die Quelle der Wahrheit sollte der Monitor sein, der das Problem bereits erkennt.

Sie veröffentlichen und nirgends verlinken. Wie in Schritt 3 gilt: Eine Statusseite, die live ist, aber weder von Website noch Docs noch Support-Flow verlinkt wird, findet im entscheidenden Moment niemand. Teste Auffindbarkeit genauso wie Alerts: Frag, wo ein Kunde zuerst suchen würde.