Statusseiten, die sich aus Live-Daten selbst aktualisieren

Was sind Statusseiten?

Statusseiten zeigen den aktuellen Zustand eines Dienstes, aufgeteilt in Komponenten wie API, Web-App, Checkout oder Login. Eine öffentliche Statusseite sagt Ihren Kunden, ob ein Problem bei Ihnen liegt und was Sie dagegen tun. Eine interne Statusseite gibt Support, Vertrieb und Engineering eine gemeinsame Sicht auf eingeschränkte Abhängigkeiten, laufende Incidents und geplante Wartungen. Beide beantworten dieselbe Frage so schnell wie möglich: Funktioniert es gerade?

Die meisten Teams beginnen mit einer manuell gepflegten Seite. Jemand muss den Ausfall bemerken, sich in ein separates Tool einloggen, eine Komponente auf „eingeschränkt“ setzen und ein Update schreiben. Während eines echten Incidents ist genau diese Person meist mit der Behebung beschäftigt – die Seite hinkt der Realität hinterher, manchmal um eine Stunde oder mehr. Eine Statusseite, die nur aktualisiert wird, wenn jemand daran denkt, verliert Vertrauen genau dann, wenn es am wichtigsten ist.

Warum automatisierte Statusseiten wichtig sind

Ein Ausfall erzeugt zwei Probleme: den technischen Fehler und die Kommunikationslücke drumherum. Wenn Kunden nicht erkennen, ob ein Problem lokal oder global ist, eröffnen sie Tickets, schreiben in sozialen Netzwerken und eskalieren an ihre Ansprechpartner. Jeder dieser Kontakte kostet Zeit, die das Team lieber in die Wiederherstellung investieren würde.

Statusseiten, die aus Live-Health-Daten gespeist werden, schließen diese Lücke. Sobald ein synthetischer Check an mehreren Standorten fehlschlägt oder ein SLO sein Error Budget schnell verbraucht, ändert die betroffene Komponente ihren Zustand. Incident Commander ergänzen dann den menschlichen Kontext – Umfang, Workaround, Zeitpunkt des nächsten Updates –, statt zuerst die Grundfakten auf der Seite herstellen zu müssen. Das Ergebnis: schnellere, konsistentere Kommunikation, weniger Last im Support und insgesamt eine kürzere Time to Resolve.

Signale für den Komponentenstatus

Eine Statusseite ist nur so gut wie die Signale dahinter. In Obseria kombinieren Sie pro Komponente mehrere Quellen:

• Synthetische Checks von über 50 Standorten, die zeigen, ob ein Endpoint von außen erreichbar ist und korrekt antwortet.
• SLO-Burn-Rate, also wie schnell das Error Budget für Verfügbarkeit oder Latenz verbraucht wird.
• Golden Signals wie Fehlerrate und Latenz der zugrunde liegenden Services aus Traces und Metriken.
• Offene Incidents mit ihrem Schweregrad, damit ein ausgerufener SEV1 immer auf den betroffenen Komponenten erscheint.
• Real User Monitoring, etwa ein plötzlicher Rückgang erfolgreicher Seitenaufrufe in einer Region.

Jede Regel führt zu einem Zustand: betriebsbereit, eingeschränkte Performance, teilweiser Ausfall oder schwerer Ausfall. Sie legen Schwellenwerte fest und wie lange eine Bedingung bestehen muss, bevor sich die Seite ändert. So vermeiden Sie Flattern bei kurzen Spitzen.

So erstellt Obseria Statusseiten

Obseria-Statusseiten bauen auf dem Service-Katalog und Obseria TopoGraph auf. Sie wählen Services, Checks und SLOs und gruppieren sie zu Komponenten, die für Ihre Zielgruppe sinnvoll sind. Ein Kunde muss nicht wissen, dass „Checkout“ von sechs Microservices und einem Payment-Gateway abhängt. Da die Topologie bekannt ist, kann eine ausgefallene Abhängigkeit automatisch die richtigen Komponenten als eingeschränkt markieren.

Incidents aus dem Obseria-Incident-Management lassen sich mit Komponenten verknüpfen. Updates aus der Incident-Timeline veröffentlichen Sie mit einem Klick auf der Statusseite – Incident-Channel und öffentliche Seite erzählen nie unterschiedliche Geschichten. Geplante Wartungsfenster erscheinen vorab und unterdrücken währenddessen Alerts für die betroffenen Services. Die Uptime-Historie wird aus denselben Daten berechnet wie Ihre SLO-Dashboards, sodass die Zahlen auf der Seite zu Ihren Reports passen.

Öffentliche Seiten laufen unter Ihrer eigenen Domain und in Ihrem Branding. Interne Seiten sind per SSO und RBAC geschützt und zeigen deutlich mehr Details, etwa den Zustand von Abhängigkeiten, Regionen und Dashboard-Verweise für den Support.

Best Practices für Statusseiten

1. Komponenten aus Nutzersicht modellieren. Nennen Sie Funktionen, die Kunden kennen, keine internen Service-Namen.
2. Erkennung automatisieren, Kontext durch Menschen. Signale setzen den Zustand, Menschen schreiben Erklärung, Auswirkung und nächsten Update-Zeitpunkt.
3. Haltezeiten nutzen. Eine Bedingung sollte einige Minuten bestehen, bevor sich der öffentliche Status ändert.
4. Updates im festen Rhythmus. Legen Sie während eines Incidents ein Update-Intervall fest und halten Sie es ein, auch ohne Neuigkeiten.
5. Zielgruppen trennen. Halten Sie die öffentliche Seite einfach und zeigen Sie Details auf der internen Seite.
6. Nach Incidents prüfen. Klären Sie im Post-Mortem, ob die Seite zum richtigen Zeitpunkt umgeschaltet hat, und passen Sie die Regeln an.