Eine gute Statusseite sagt bei einer Störung vier Dinge, und zwar in dieser Reihenfolge: was betroffen ist, wie schlimm es ist, was du gerade weißt und wann du dich wieder meldest. Sie sagt nicht, wer Bereitschaft hat, welcher Server Ärger macht, und sie verlinkt auch nicht dein internes Runbook – diese Informationen gehören woandershin. Auf der öffentlichen Seite verwirren sie entweder deine Kunden oder geben Details preis, die du gar nicht teilen wolltest.
Die meisten Teams bekommen die öffentliche Hälfte gut hin, lösen aber nie die zweite: Wo landen die Informationen für die Leute, die die Störung beheben? Dieser Beitrag behandelt beides.
Was Kunden auf der Statusseite wirklich lesen müssen
Ein Update auf der Statusseite erfüllt seinen Zweck, wenn ein gestresster, nicht technischer Leser in fünf Sekunden beantworten kann: „Betrifft mich das, und wann ist es behoben?“ Das heißt:
- Welche Dienste betroffen sind – so benannt, wie Kunden sie kennen („Checkout“, nicht „payments-worker-3“).
- Der aktuelle Schweregrad, klar formuliert – eingeschränkte Leistung, teilweiser Ausfall oder größerer Ausfall, keine interne Ticketpriorität.
- Was du bisher weißt, in einfacher Sprache, ohne internen Jargon und ohne Schuldzuweisungen.
- Ein Zeitpunkt für das nächste Update, auch wenn das nächste Update nur „wir untersuchen weiter“ lautet.
Die meisten Statusseiten (auch die großen – die Statusseiten von GitHub und Cloudflare folgen beide diesem Muster) führen eine Störung im Verlauf durch eine kleine Zahl von Zuständen:
| Zustand | Was er dem Leser sagt |
|---|---|
| Investigating | Etwas stimmt nicht; wir prüfen das Ausmaß |
| Identified | Wir kennen die Ursache |
| Monitoring | Ein Fix ist eingespielt; wir beobachten, ob er hält |
| Resolved | Es ist vorbei |
Das ist kein formaler Standard – es gibt keinen RFC für die Formulierungen auf Statusseiten –, aber trotzdem eine Konvention, der du folgen solltest. Deine Kunden haben nämlich längst gelernt, sie bei jedem anderen SaaS-Tool zu lesen, das sie nutzen. Wer das Vokabular neu erfindet, sorgt nur für Reibung – genau in dem Moment, in dem die Leute Klarheit wollen.
TipPoste Updates in einem festen Rhythmus – auch „keine Änderung, wir untersuchen weiter“ –, statt zwischen den Meilensteinen zu verstummen. Schweigen wirkt, als hättest du aufgegeben, selbst wenn im Hintergrund aktiv gearbeitet wird.
Warum die Kundenversion für dein Team nicht taugt
Das Problem: Die Seite für Kunden ist absichtlich unvollständig. Für sie ist das richtig – für die Person, die das Problem tatsächlich behebt, ist es nutzlos. Wer um 3 Uhr nachts alarmiert wird, will nicht „wir untersuchen ein Problem beim Checkout“ lesen, sondern wissen, welche Regionen es melden, wie alt die letzte Prüfung ist, wer sonst schon dran ist und wo das Runbook für genau diesen Dienst liegt.
Heute lösen Teams das, indem sie diese Informationen ganz woanders ablegen – auf einer Wiki-Seite, in einer angepinnten Slack-Nachricht, in einer Tabelle mit Bereitschaftsnamen – und hoffen, dass die alarmierte Person sie schnell genug findet. Genau diese Lücke hat eine Statusseite nie geschlossen: Sie sagt Kunden, dass etwas kaputt ist, wurde aber nie dafür gebaut, deinem eigenen Team zu sagen, wie es sich beheben lässt.
Was eine Statusseite stattdessen deinem Team zeigen sollte
Die Rohdaten hat eine Statusseite bereits: Sie baut auf deinen Monitoring-Checks auf und weiß daher genau, welcher Dienst ausgefallen ist, welche Regionen noch melden und seit wann. Was fehlt, ist nicht mehr Monitoring – sondern eine zweite Lesart derselben Seite, geschrieben für die Leute, die das Problem beheben, statt für die, die davon betroffen sind.
Genau das ist die Team view von InfraNest. Öffne eine beliebige Statusseite, und hinter deinem normalen Login gibt es eine zweite Ansicht davon, die Folgendes zeigt:
- Die Leiste oben – Gesamtstatus, wie viele Dienste der Seite laufen, Uptime der letzten 30 Tage und wann das nächste Wartungsfenster beginnt.
- Bereitschaft – Freitext, denn ein Dienstplan ist ein eigenes Produkt; die meisten Teams brauchen nur einen Namen, eine Nummer und einen Channel.
- Gerade offen – jede laufende Störung, jeweils mit Link zum öffentlichen Bericht – also genau dem Link, den du tatsächlich in ein Support-Ticket einfügst.
- Dienste, letzte 30 Tage – genau so gruppiert, wie Kunden sie sehen, mit Uptime-Balken, dem Zeitpunkt der letzten Prüfung, der Zahl der Monitoring-Regionen, die noch melden, und einem Runbook-Button für jeden Dienst, der eins hat.
Weder der Bereitschaftskontakt noch die Runbook-Links gelangen je auf die öffentliche Seite. Sie werden nur an Personen ausgeliefert, die in deiner Organisation angemeldet sind – ein Kunde, der zufällig das Passwort deiner Seite kennt, sieht also weiterhin nur die öffentliche Seite und sonst nichts. Die Ansicht aktualisiert sich außerdem alle 30 Sekunden selbst, du kannst sie also während der gesamten Störung bedenkenlos auf einem zweiten Monitor offen lassen.
Statusseite für dein Team einrichten
Beides findest du an derselben Stelle wie die Statusseite selbst:
- Geh zu Status Pages und öffne die Seite.
- Fülle On-call contact aus – einen Namen, eine Telefonnummer, einen Link zu deinem PagerDuty-Dienstplan oder einen Slack-Channel. Leere das Feld, wenn jemand aus der Bereitschaft rotiert; ein veralteter Name hier ist der Grund, warum die Bereitschaft vom letzten Quartal immer noch alarmiert wird.
- Öffne den Tab Components, klicke auf einen Dienst und fülle Runbook link aus. Verlinke das Dokument für genau diesen Dienst, nicht die Startseite deines Wikis – der ganze Sinn ist, dass die alarmierte Person auf der richtigen Seite landet und nicht auf einem Index, den sie erst durchsuchen muss.
Der Runbook-Link muss mit https:// beginnen. Beides gehört zu den privaten Statusseiten – wenn dein Tarif die Team view nicht enthält, weist dich die Seite darauf hin, und alles andere funktioniert wie bisher.
Eine Störung, zweimal erzählt
Dieselbe Störung, zwei Zielgruppen:
Öffentliche Seite (für Kunden):
Investigating – Wir beobachten erhöhte Fehlerraten beim Checkout. Wir sehen uns das an und posten innerhalb von 30 Minuten ein Update.
Team view (im selben Moment):
Checkout: 2 von 3 Regionen melden Ausfall, zuletzt geprüft vor 14 s. Bereitschaft: Priya, +44 7xxx, #incidents. Runbook: checkout-5xx-playbook.
Die erste Version ist ruhig, korrekt und sagt einem Kunden genau so viel, wie er wissen muss. Die zweite ist dicht, konkret und bringt die Bereitschaft in Bewegung – ohne eine einzige Slack-Nachricht mit „Weiß jemand, wem das gehört?“.
WarningFüge keine internen Details – Servernamen, Regionszahlen, Bereitschaftsnamen – in das öffentliche Störungs-Update ein. Dem Leser hilft das nicht, und es ist eine Sache mehr, die du später schwärzen müsstest, falls die Seite jemals extern geteilt wird.
Nach Behebung der Störung behält der öffentliche Bericht seine eigene dauerhafte URL – praktisch, denn Support-Tickets, die darauf verweisen, bleiben oft noch lange offen, wenn die Seite selbst längst beim nächsten Thema ist. Wenn du diese Links in dein Ticketsystem überträgst, lies Störungen auf der Statusseite mit Support-Gesprächen verknüpfen.
Kurze Checkliste für deine Statusseite
- Statusseite aus deinen echten Monitoren aufgebaut, nicht von Hand eingetippt – siehe Statusseite erstellen.
- Ein Bereitschaftskontakt auf der Seite eingetragen und aktuell gehalten.
- Ein Runbook-Link bei jedem Dienst, der eins hat.
- Ein fester Update-Rhythmus, mit deinem Team abgestimmt – auch für Updates wie „noch keine Änderung“.
Häufige Fragen
Du willst das Gesamtbild, bevor du eine einrichtest? Fang mit Statusseiten an.
Häufig gestellte Fragen
#Wie sieht der übliche Ablauf einer Störung auf einer Statusseite aus?
Die meisten Statusseiten, auch die von GitHub und Cloudflare, führen eine Störung durch die Zustände Investigating, Identified, Monitoring und Resolved. Das ist eine weit verbreitete Konvention, kein formaler Standard – es gibt keinen RFC, der die Formulierungen auf Statusseiten regelt.
#Wie oft sollte ich während einer Störung Updates posten?
So oft, dass Schweigen nie so wirkt, als hättest du aufgegeben – viele Teams setzen auf einen festen Rhythmus, etwa alle 30 Minuten, auch wenn es nichts Neues gibt. Denn „wir untersuchen weiter“ ist besser als gar kein Update.
#Was ist der Unterschied zwischen einer Statusseite und einer Team view?
Eine Statusseite ist öffentlich und beantwortet Kunden eine Frage: Ist etwas kaputt? Eine Team view ist dieselbe Seite, neu geschrieben für die Bereitschaft – mit der Information, wer Bereitschaft hat, offenen Störungen und Runbook-Links pro Dienst. Nichts davon gelangt je auf die öffentliche Seite.
#Können Kunden den Bereitschaftskontakt oder die Runbook-Links sehen?
Nein. In InfraNest werden beide nur an Personen ausgeliefert, die in deiner Organisation angemeldet sind. Wer das Passwort einer passwortgeschützten Seite kennt, sieht trotzdem nur die öffentliche Seite, nie die Team view.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
