Diese Anleitung geht die Entscheidungen hinter einer Statusseite für ein SaaS durch: was darauf gehört, wann ein Uptime-Monitor etwas als Ausfall werten sollte, wie man Updates zu Vorfällen formuliert und wo die Seite liegen sollte. Das Beispiel sind die Statusseite und die Uptime-Monitore, die ich gerade in Kookee eingebaut habe, und die Screenshots stammen von Lumen, dem ausgedachten Analytics-Produkt in meinem Demo-Projekt. Die Monitore mussten sich früher beweisen als geplant: Beim Aufnehmen der Screenshots habe ich versehentlich das Portal des Demo-Projekts abgeschaltet, und seine zwei Monitore haben es 68 und 78 Sekunden später bemerkt.
Was auf eine Statusseite gehört
Eine brauchbare Statusseite hat vier Teile:
die Teile deines Produkts, jeder mit seinem aktuellen Status;
die offenen Vorfälle, mit dem, was du bisher weißt;
geplante Wartungen, bevor sie beginnen;
die jüngste Vergangenheit: die Vorfälle der letzten Monate und wie lange jeder Teil in dieser Zeit verfügbar war.
Darüber fasst eine Zeile die ganze Seite zusammen, damit jemand, der nur wissen will, ob das Problem bei ihm liegt, danach aufhören kann zu lesen. Auf Kookees Seite steht dort „Alle Systeme betriebsbereit“, „Leichte Störung“, „Schwerer Ausfall“ oder „Wartung läuft“, abgeleitet aus den Komponenten und den offenen Vorfällen.
Benenne Komponenten so, wie deine Kunden es tun
Eine Komponente ist etwas, das ein Kunde mit dem abgleichen kann, was er sieht. Lumen listet Dashboards, Data ingestion, Public API, Email reports und Help center. Seine Queue-Worker oder seine Datenbank listet es nicht, weil außerhalb des Teams niemand weiß, was die tun. Im Screenshot oben nennt Lumens ausgedachter Vorfall Email reports als betroffene Komponente, und weiter unten auf der Seite steht bei dieser Komponente „Eingeschränkte Leistung“. Ein Kunde, dem ein geplanter Bericht fehlt, kann das mit dem abgleichen, was er sieht.
Kookee erlaubt 10 Komponenten bei Free und 50 bei Pro. Jede bekommt einen Balken pro Tag, gefärbt nach dem schlechtesten Status des Tages: 90 Tage auf einem breiten Bildschirm, die letzten 30 auf dem Handy und keine, wenn du Uptime anzeigen ausschaltest.
Entscheide, wann eine Website wirklich ausgefallen ist
Ein Uptime-Monitor ruft eine URL in festen Abständen auf und muss entscheiden, ab wann ein Fehler ein Ausfall ist. Kookees Regel: drei fehlgeschlagene Prüfungen in Folge. Nach einer fehlgeschlagenen Prüfung prüft der Monitor 20 Sekunden später erneut, die drei Fehlschläge dauern also bei jedem Intervall etwa 40 Sekunden, länger, wenn jede Prüfung bis zum Timeout wartet. Das Intervall bestimmt nur, wie schnell der erste Fehlschlag kommt: Bei Pro und Ultra kann ein Monitor jede Minute prüfen, bei Free höchstens alle fünf Minuten. Eine einzelne fehlgeschlagene Prüfung löst nichts aus, und nach zwei erfolgreichen Prüfungen in Folge gilt der Monitor wieder als erreichbar.
So sah das aus, als ich das Demo-Portal abgeschaltet habe. Das Portal ging um 08:02:36 UTC aus. Die Monitore meldeten den Ausfall um 08:03:44 und 08:03:54, jeweils nach drei 404-Antworten, und der Monitor für das Hilfecenter eröffnete einen Vorfall als Entwurf: „Help center is down“. Um 08:04:18 war das Portal wieder an, um 08:05:24 und 08:05:34 meldeten die Monitore wieder „Erreichbar“, und der Entwurf wurde von selbst als behoben markiert, ohne je auf der öffentlichen Seite zu erscheinen. Der Ausfall, den jeder Monitor aufgezeichnet hat, dauerte etwa so lange wie der echte und lag an beiden Enden rund eine Minute dahinter: der Preis dafür, einen Ausfall erst zu bestätigen und dann zu melden.
Ein paar weitere Regeln entscheiden, ob du dem Monitor trauen kannst. Ein Monitor, der noch nie erfolgreich war, benachrichtigt nur dein Team, denn ein Tippfehler in der URL soll deinen Kunden keinen Ausfall zeigen, den es nie gab. War er einmal erreichbar, setzt ein ausgefallener Monitor seine Komponente auf „Schwerer Ausfall“, egal was er sonst tun soll, damit die Seite nicht „Betriebsbereit“ anzeigt, während die Prüfung fehlschlägt. Und wenn für die Komponente gerade eine geplante Wartung läuft, hält der Monitor den Ausfall bis zum Ende des Wartungsfensters zurück.
Was danach passiert, legst du für jeden Monitor fest: Nur benachrichtigen, Vorfall als Entwurf eröffnen oder sofort Vorfall veröffentlichen. Ein Entwurf gibt dir einen fertigen Vorfall, den du prüfen und umformulieren kannst, bevor er rausgeht. Sofort zu veröffentlichen passt zu einer URL, deren Ausfall immer Kunden trifft, etwa dem Health-Check deiner API.
Schreib Updates, mit denen Kunden etwas anfangen können
Ein Vorfall besteht aus einem Titel und einer Reihe von Updates. Jedes Update hat einen Status, und für Vorfälle kennt Kookee genau vier: „Wird untersucht“, „Ursache gefunden“, „Wird beobachtet“ und „Behoben“. Der Titel sollte benennen, was Kunden bemerken („Dashboards luden langsam“), nicht die Ursache.
Jedes Update sollte beantworten, was ein Kunde als Nächstes fragen würde. In Lumens behobenem Vorfall unten sagt das erste Update, was betroffen ist, mit einer Zahl: „Einige Dashboards brauchen mehr als 20 Sekunden zum Laden.“ „Ursache gefunden“ nennt die Ursache, sobald sie bekannt ist: „Das Release von heute Morgen hat geändert, wie große Funnel-Diagramme abgefragt werden.“ „Wird beobachtet“ sagt, was das Team im Blick behält, bevor es den Fehler für behoben erklärt: „Wir beobachten die Ladezeiten in der nächsten Stunde.“ Der Vorfall mit den E-Mail-Berichten weiter oben beantwortet die andere Frage, die Kunden stellen, nämlich ob etwas verloren geht: „Verzögerte Berichte werden trotzdem verschickt, keiner geht verloren.“
In Kookee setzt jedes Update außerdem den Status jeder Komponente, die es betrifft, sodass ein einziges Update den Vorfall und die Komponentenliste ändert.
Kündige Wartungen an, bevor sie beginnen
In Kookee ist ein Wartungsfenster öffentlich, sobald du es planst, unter „Anstehende Wartungen“. Zwischen Beginn und Ende läuft es, und seine Komponenten zeigen „In Wartung“. Danach ist es abgeschlossen, ohne dass jemand es von Hand starten oder beenden muss. Schreib dazu, was Kunden bemerken könnten und wie lange, so wie Lumen bei seinem Datenbank-Upgrade: „Dashboards und die API können während des Fensters bis zu 15 Minuten langsam antworten.“
Wie Kookee die Uptime berechnet
Kookee zählt nur Zeit im Status „Schwerer Ausfall“ als Ausfallzeit. „Eingeschränkte Leistung“ und Teilausfälle färben den Tagesbalken, senken aber die Zahl nicht. Der Prozentwert umfasst 90 Tage und beginnt mit dem Tag, an dem die Komponente hinzugefügt wurde, frühere Tage sind also grau, nicht grün. Er wird abgerundet: 99,996 % erscheint als 99,99 %, nie als 100,00 %.
Hoste sie getrennt von dem, worüber sie berichtet
Eine Statusseite, die vom selben System ausgeliefert wird, das sie beschreibt, fällt mit ihm aus. Kookees gehostete Seite liegt unter <your-project>.kookee.dev/status, getrennt von deinen eigenen Servern. Willst du sie auf deiner eigenen Domain haben, baust du dieselbe Seite aus @kookee/react/status: StatusHeadline und StatusOverview für die Seite, StatusIncidentArticle für jeden Vorfall. Liefere sie nicht von der App aus, über die sie berichtet, sondern etwa von einem statischen Hosting, und lass den Browser den Status aus Kookees API lesen:
import { useStatus } from '@kookee/react';
import { StatusHeadline, StatusOverview } from '@kookee/react/status';
const { data: status } = useStatus({ refreshSeconds: 60 });
if (!status) return null;
<StatusHeadline status={status} />
<StatusOverview status={status} incidentHref="/status/incidents/{id}" />Abrufe des Status zählen nicht zu deinen monatlichen API-Anfragen. In jeder der vier Starter-Vorlagen von Kookee fügt KOOKEE_STATUS=true die Seite /status und eine Seite pro Vorfall hinzu. Für Kookee selbst gilt dieselbe Einschränkung: Die Seite und die Komponenten lesen aus Kookees API, und wenn diese API ausfällt, laden sie auch nicht.
So richtest du sie in Kookee ein
Öffne Statusseite, geh zum Tab Komponenten und klicke für jeden Teil, den Kunden sehen, auf Komponente hinzufügen.
Öffne Uptime-Monitor, klicke auf Monitor hinzufügen, gib die URL ein, wähle Prüfintervall und Komponente und lege unter Bei einem Ausfall fest, was passiert.
Öffne Öffentliches Portal, schalte Öffentliches Portal aktivieren ein, falls es aus ist, und hake unter Portal-Module die Statusseite an.
Geh zurück zu Statusseite und klicke auf Statusseite ansehen.
Eine Statusseite einrichten erklärt Vorfälle und Wartungen, Deine Website mit Uptime-Checks überwachen jede Einstellung eines Monitors.
Was Kookees Statusseite noch nicht kann
Besucher können Updates nicht per E-Mail oder RSS abonnieren. Es gibt keine SMS-Benachrichtigungen und keine Bereitschaftspläne, Monitore prüfen nur per HTTP und HTTPS, und private Statusseiten gibt es nicht. Die gehostete Seite kann keine eigene Domain bekommen; auf deine Domain bringst du sie mit den React-Komponenten.
FAQ
Ist die Statusseite kostenlos? Ja. Jeder Plan hat die Statusseite und Uptime-Monitore. Free hat 10 Komponenten und 3 Monitore, die höchstens alle 5 Minuten prüfen; Pro hat 50 Komponenten und 20 Monitore, die bis zu einmal pro Minute prüfen.
Wer erfährt, wenn ein Monitor ausfällt? Die Inhaber und Admins des Projekts, im Dashboard und per E-Mail. Webhooks können ein monitor.down-Ereignis empfangen, und bei Pro und Ultra können die Integrationen für Slack, Discord und Telegram es in den Kanal deines Teams posten.
Kann ein KI-Assistent Vorfälle veröffentlichen? Ja. Über Kookees MCP-Server kann ein Assistent mit Schreibzugriff den Status lesen und Vorfälle anlegen, aktualisieren und als behoben markieren.
Weiterlesen
Eine Statusseite einrichten: jeder Schritt im Dashboard, von den Komponenten bis zur Wartung.
Deine Statusseite auf deiner eigenen Website zeigen: die React-Komponenten, die API und die Starter-Vorlagen.
Deine Webhooks sollten der URL, die sie bekommen, nicht trauen: warum ein Server, der URLs von Kunden aufruft, prüfen muss, wohin sie zeigen.