Statusseite bauen: Komponenten, Störungen und Verfügbarkeitschecks

Eine Statusseite zeigt deinen Nutzern an einer Stelle, ob dein Dienst funktioniert. Um eine zu bauen, brauchst du eine Liste von Komponenten (Website, API, Zahlungen, E-Mail-Versand), einen aktuellen Status für jede davon, Störungen mit zeitgestempelten Updates, eine Historie vergangener Störungen und optional Abos, damit Leute von Problemen erfahren, ohne nachschauen zu müssen. Die Seite selbst ist einfach. Die wichtige Entscheidung ist, wo sie läuft: Eine Statusseite muss auch dann erreichbar sein, wenn deine App ausgefallen ist. Deshalb sollte sie weder Hosting, Datenbank noch Deployment-Pipeline mit dem teilen, worüber sie berichtet.

Wofür eine Statusseite da ist

Wenn etwas kaputt geht, wollen Nutzer drei Dinge wissen: Liegt es nur an mir, wisst ihr davon, und wann wird es behoben? Eine Statusseite beantwortet alle drei Fragen, ohne dass Supporttickets überquellen. Sie schafft außerdem über die Zeit Vertrauen, denn eine sichtbare Störungshistorie mit ehrlichen Berichten zeigt, wie du mit Problemen umgehst.

Sie ist kein Changelog. Neue Funktionen gehören auf eine Changelog-Seite; Ausfälle und Wartungsarbeiten gehören hierher.

Was die Seite braucht

Daten

Komponentenstatus sind meist eine kurze feste Liste: Betriebsbereit, Eingeschränkte Leistung, Teilausfall, Totalausfall, In Wartung.

Seiten

• Öffentliche Statusseite: ein Gesamtbanner („Alle Systeme betriebsbereit“ oder der schlechteste aktuelle Status), jede Komponente mit ihrem Status, eine aktive Störung mit ihren Updates, anstehende Wartung und ein 90-Tage-Verlaufsbalken, falls du Prüfdaten hast.
• Störungsseite: der vollständige Verlauf der Updates zu einer Störung, mit eigener URL, damit der Support sie verlinken kann.
• Historie: vergangene Störungen nach Monaten.
• Abo: E-Mail-Anmeldung mit Bestätigung und Einstellungen pro Komponente.
• Admin: Störung anlegen, Updates veröffentlichen, Komponentenstatus ändern, Wartung planen.

Berechtigungen

Die Öffentlichkeit sieht alles, was veröffentlicht ist. Nur dein Team kann etwas veröffentlichen. Halte den Admin-Login nach Möglichkeit getrennt vom Login deiner Hauptapp, damit ein Ausfall deines Authentifizierungsdienstes dich nicht von deiner eigenen Statusseite aussperrt.

Die wichtigste Entscheidung: unabhängig bleiben

Hier scheitern die meisten selbst gebauten Statusseiten. Wenn deine Statusseite

• auf demselben Server oder Hosting-Konto wie deine App läuft,
• dieselbe Datenbank liest,
• hinter derselben Domain-Einrichtung oder CDN-Konfiguration hängt
• oder von derselben Pipeline ausgerollt wird,

dann reißt sie viele Ausfälle mit, genau dann, wenn Leute sie brauchen. Praktische Schritte:

• Eigenes Hosting. Ein anderes Projekt oder ein anderer Anbieter als die Hauptapp.
• Eine eigene Subdomain, etwa status.beispiel.de, separat im DNS eingetragen. Siehe wie Domains und DNS funktionieren.
• Eigene Daten. Störungen liegen im eigenen Speicher der Statusseite, nicht in der Datenbank deiner App.
• Ein statischer Fallback. Manche Teams machen die öffentliche Seite statisch und bauen sie bei jedem Update neu, sodass praktisch nichts kaputtgehen kann.

Manuelle Updates oder automatische Checks

Manuell (ein guter Start)

Dein Team trägt Störungen und Statusänderungen von Hand über die Admin-Seite ein. So funktionieren viele Statusseiten in der Praxis, denn eine menschliche Einschätzung („Zahlungen sind bei manchen Kartentypen langsam“) ist nützlicher als ein automatischer roter Punkt.

Um Probleme schnell mitzubekommen, nutze einen externen Uptime-Monitor, der deine App etwa jede Minute prüft und dich per E-Mail, SMS oder Chat alarmiert. Viele Monitoring-Dienste haben kostenlose Tarife.

Automatisch

Automatisierung heißt: Etwas prüft regelmäßig jede Komponente und aktualisiert ihren Status. Dafür braucht es Code, der nach Zeitplan läuft, und zwar von außerhalb der Infrastruktur deiner Hauptapp. Zwei gängige Muster:

• Ein externer Monitor ruft deine Statusseite über einen Webhook auf, wenn eine Prüfung fehlschlägt oder sich erholt, und die Statusseite aktualisiert die Komponente.
• Ein geplanter Job im eigenen Hosting der Statusseite pingt jede Komponente an und speichert das Ergebnis. Prüfe vorher, wie dein Hosting geplante Aufgaben handhabt; unser Leitfaden zu Hintergrundjobs erklärt die Optionen.

Automatische Änderungen können bei einer wackeligen Verbindung hin- und herspringen (oben, unten, oben). Verlange zwei oder drei fehlgeschlagene Prüfungen, bevor sich ein Status ändert, und lass einen Menschen bestätigen, bevor eine große Störung angekündigt wird.

Störungs-Updates schreiben

• Früh veröffentlichen. „Wir untersuchen Meldungen über fehlgeschlagene Logins“ nach wenigen Minuten ist besser als eine perfekte Nachricht eine Stunde später.
• Sag, was Nutzer merken, nicht, was intern kaputtgegangen ist.
• Nenn die Zeit des nächsten Updates und halte sie ein.
• Schließe mit einer kurzen Zusammenfassung, sobald alles behoben ist: was passiert ist, wie lange es gedauert hat, was du änderst.

Ein erster Prompt, der funktioniert

Baue eine eigenständige Statusseite für unsere App Parcelio, die getrennt unter status.parcelio.com gehostet wird. Komponenten: Website, Tracking-API, Benachrichtigungen, Zahlungen, jeweils mit einem der Status Betriebsbereit, Eingeschränkte Leistung, Teilausfall, Totalausfall oder In Wartung. Die öffentliche Seite zeigt ein Gesamtbanner mit dem schlechtesten aktuellen Status, jede Komponente mit ihrem Status, aktive Störungen mit zeitgestempelten Updates (neueste zuerst), anstehende Wartung und eine Liste vergangener Störungen nach Monaten. Jede Störung hat eine eigene Seite. Füge eine passwortgeschützte Admin-Seite hinzu, um Störungen anzulegen (Titel, Auswirkung, betroffene Komponenten), Updates zu veröffentlichen (Nachricht und Status: Untersuchung, Ursache gefunden, Überwachung, Behoben), Komponentenstatus zu ändern und Wartung zu planen. Ergänze einen Endpunkt POST /api/check-result, der von einem externen Monitor einen Komponentennamen und Up/Down annimmt, mit einem geheimen Token geschützt ist und eine Komponente erst nach drei aufeinanderfolgenden Fehlern als eingeschränkt markiert. Speichere alles in der eigenen Datenbank dieser App. Schlichtes, ruhiges Design, das auf dem Handy schnell lädt.

Bauschritte

1. Öffentliche Seite und Admin mit manuellen Störungen. Das allein ist bereits eine funktionierende Statusseite.
2. Getrennt hosten und eine Subdomain darauf zeigen lassen.
3. Störungsseiten und Historie.
4. Wartungsfenster.
5. Abos. Anmeldung per E-Mail mit Doppel-Opt-in und Benachrichtigungen bei neuen Störungen und Updates. Für E-Mails brauchst du einen Anbieter; siehe wie du E-Mails aus deiner App verschickst.
6. Monitor-Webhook, wenn du automatische Statusänderungen willst.
7. Eine Übung durchführen. Lege eine fiktive Störung an, veröffentliche Updates, löse sie auf, prüfe die E-Mails und lösche sie dann.

Häufige Fehler

• Gemeinsames Hosting mit der App. Der häufigste und zugleich schwerwiegendste Fehler.
• Eine Seite, die immer „Alle Systeme betriebsbereit“ anzeigt. Zeigt sie nie Probleme, hören Nutzer auf, ihr zu vertrauen.
• Keine Zeitstempel oder Zeitzone. Zeiten immer mit Zeitzone anzeigen.
• Der Admin-Bereich nutzt den Login deiner Hauptapp.
• Stille zwischen den Updates. „Keine Änderung, wir arbeiten weiter daran“ ist ein gültiges Update.
• Flatternde automatische Status. Verlange wiederholte Fehler, bevor sich etwas ändert.

Wann ein gehosteter Statusseiten-Dienst die bessere Wahl ist

Gehostete Statusseiten-Dienste sind genau auf das Unabhängigkeitsproblem ausgelegt: Sie laufen auf getrennter Infrastruktur, verschicken Abonnenten-Benachrichtigungen per E-Mail und SMS und enthalten oft Monitoring sowie Integrationen mit Tools für Störungsmanagement. Wenn Verfügbarkeit Teil dessen ist, wofür Kunden zahlen, oder du vertraglich verpflichtet bist, Störungen zu melden, lohnt sich meist ein eigener Dienst. Viele haben kostenlose oder günstige Tarife für kleine Teams, prüfe also zuerst.

Baue selbst, wenn du volle Kontrolle über Design und Formulierungen willst, wenn deine Anforderungen schlicht sind (wenige Komponenten, manuelle Updates) oder wenn eine Statusseite Teil eines Produkts ist, das du für andere baust.

Mit Mythex bauen

In Mythex kannst du die Statusseite als eigenes Projekt bauen, getrennt von deiner Hauptapp. Dadurch bekommt sie eigenes Hosting und eine eigene Datenbank. Beschreibe sie im Chat, prüfe sie in der Live-Vorschau, veröffentliche sie und verbinde dann eine Subdomain wie status.deinedomain.de (eigene Domains gibt es mit Pro). Beachte: Veröffentlichte Mythex-Apps und ihre Datenbanken schlafen bei Inaktivität ein und wachen beim nächsten Besuch auf. Der erste Aufruf nach einer ruhigen Phase kann deshalb langsamer sein. Eine einfache, schlanke Seite hilft dabei.

Mythex dokumentiert keine geplanten Jobs. Für automatische Checks nutzt du daher einen externen Uptime-Monitor, der einen Webhook-Endpunkt deiner Statusseite aufruft (siehe das Webhook-Rezept). E-Mail-Benachrichtigungen an Abonnenten laufen über deinen eigenen Anbieter, dessen Schlüssel als Projekt-Geheimnis gespeichert wird (Rezept zum E-Mail-Versand).

Fragen