Wie eine gute öffentliche Statusseite aussieht

Eine öffentliche Statusseite ist die Anlaufstelle für Kunden bei einer Störung. Eine gute Statusseite reduziert die Anzahl der Support-Tickets und schafft Vertrauen. Woraus sie besteht.

Was eine gute Statusseite haben muss

Aktueller Zustand jedes wichtigen Dienstes. Nicht nur "alles OK", sondern nach Komponenten aufgeschlüsselt (API, Web, Dashboard, E-Mail-Versand, Zahlungsabwicklung).
Vorfallhistorie der letzten 90 Tage. Ohne den Versuch, etwas zu verbergen - eine transparente Historie schafft Vertrauen.
Uptime-Metrik (typischerweise über 30 Tage) für jede Komponente, als transparenter Prozentwert ausgedrückt.
Geplante Wartung. Ein Banner mit Datum und einer Beschreibung dessen, was nicht verfügbar sein wird.
Aktiver Vorfall mit einer Zeitleiste der Updates. Investigating → Identified → Monitoring → Resolved.
Ein Abonnementformular. Kunden erhalten eine E-Mail, wenn sich der Status ändert, und müssen die Seite nicht wiederholt prüfen.

Eine klare Komponentenhierarchie

Statt eines einzelnen "Monitor"-Eintrags teilen Sie den Dienst in Komponenten auf, die aus Kundensicht Sinn ergeben:

Web App - Frontend (von Besuchern genutzt)
API - Backend für programmatische Integrationen
Auth / Login - Anmeldung
Email delivery - transaktionale E-Mails
Background jobs - Sync, Abrechnung, Exporte
Status page - Meta-Komponente: auch die Statusseite selbst kann ausfallen (deshalb sollte sie auf einer anderen Infrastruktur als das Produkt laufen)

Vorfallkommunikation: Anatomie eines guten Updates

Halten Sie bei einer echten Störung diese Phasen ein:

Investigating - "Wir haben ein Problem mit [Komponente] festgestellt. Das Team untersucht die Ursache." (innerhalb von 5 Min. nach der Erkennung)
Identified - "Die Ursache ist [kurz]. Wir arbeiten an einer Lösung. ETA [Zeit]." (sobald Sie wissen, was das Problem verursacht)
Monitoring - "Wir haben einen Fix ausgerollt. Wir beobachten, ob das Problem erneut auftritt." (nach dem Deployment der Lösung)
Resolved - "Der Vorfall ist behoben. Dauer X Minuten. Ein Postmortem folgt." (nach bestätigter Wiederherstellung)

Jede Phase erhält einen Zeitstempel und ein eigenes Update. Veröffentlichen Sie nach dem Vorfall ein Post-Mortem (Root Cause, Timeline und Maßnahmen, die eine Wiederholung verhindern).

Regel: Verwenden Sie niemals vage Formulierungen wie "experiencing some issues". Kunden wollen Konkretes: "Login schlägt bei ~30 % der Versuche fehl. Die API funktioniert normal. Das Web ist nur im Read-only-Modus verfügbar."

Hosting: das Prinzip der unabhängigen Infrastruktur

Die Statusseite muss auf einer anderen Infrastruktur laufen als der überwachte Dienst. Wenn Ihre AWS-Region ausfällt, fällt eine in derselben Region gehostete Statusseite mit ihr aus - genau in dem Moment, in dem Kunden sie am dringendsten brauchen.

Praktische Lösungen:

Hosting über ein externes SaaS (ePulz.io, Better Stack, Atlassian Statuspage)
Eine eigene statische Seite auf einem CDN (Cloudflare Pages, Netlify) mit dem API-Endpoint anderswo
Im Extremfall eine minimale statische Seite auf Cloudflare mit manuell aktualisiertem Text

Subscribers: E-Mail und Webhook

Kunden wollen die Statusseite nicht ständig aktualisieren. Eine gute Seite unterstützt daher:

Email subscribers - in ePulz.io für eingeloggte Nutzer mit kostenpflichtigem Plan verfügbar (wir sammeln Abonnements nur von verifizierten Konten, nicht von anonymen Besuchern)
Webhook - für Teams, die den Status in ihr eigenes Slack oder PagerDuty integrieren möchten

Anti-Pattern: Probleme verbergen

Die Versuchung, eine Störung als "degraded" statt "down" zu kennzeichnen (oder sie gar nicht anzuzeigen), ist groß, aber kurzsichtig:

Kunden bemerken die Störung ohnehin (über eigenes Monitoring, Support-Tickets oder soziale Netzwerke)
Sie verlieren Vertrauen, wenn sie feststellen, dass der Status während einer offensichtlichen Störung "OK" meldet
Sie verlieren das reale Bild des Uptime-Trends, das Sie für interne Entscheidungen brauchen

Die beste Strategie ist radikale Transparenz. GitLab, Cloudflare und Stripe veröffentlichen detaillierte Post-Mortems auch bei peinlichen Fehlern, und die Community schätzt das.

SEO und Brand

Eine Statusseite sollte:

Auf einer stabilen und leicht zu merkenden URL für den Servicestatus liegen
Ein eigenes Branding (Logo, Farben) haben - der Kunde muss sehen, dass er weiterhin auf Ihrer Seite ist
In Google indexiert sein (bessere Sichtbarkeit bei der Suche nach "[Brand] down")
Von der Hauptseite verlinkt sein (Footer "Servicestatus")

Fazit

Eine Statusseite ist keine Dekoration. Sie ist ein operatives Werkzeug, das während eines Vorfalls die Support-Last reduziert und langfristiges Vertrauen aufbaut. Die Investition von ein paar Stunden in die richtige Konfiguration zahlt sich schon bei der ersten größeren Störung aus.

Erstellen Sie eine Statusseite in 5 Minuten

ePulz.io Statusseiten mit eigenem Branding, Email-Subscribers und Incident-Timeline. 7 Tage kostenlos.

ePulz.io ausprobieren →