Eine Statusseite, der deine Kunden glauben — und mit der dein Team arbeiten kann.

Aus deinem Monitoring. Hinter jedem Dienst auf der Seite steht einer deiner Checks, der Status ist also das, was dieser Check zuletzt gemeldet hat, und das Banner oben wird aus allen zusammen berechnet — der schlimmste gewinnt. Es gibt nichts von Hand zu pflegen und keine zweite Kopie der Wahrheit. Du wählst, welche Checks erscheinen und wie sie öffentlich heißen, ein Monitor namens „App — northwind-app.dev“ kann also als „Web-App“ auftauchen, und die Zertifikats- und Datenbankport-Prüfungen können intern bleiben.

Dieselbe Statusseite, neu geschrieben für die Leute, die das Problem beheben, in InfraNest hinter deinem normalen Login. Deine öffentliche Seite beantwortet eine Frage — ist etwas kaputt — und bewusst sonst nichts. Die Teamansicht ergänzt, was eine diensthabende Person braucht: wer Rufbereitschaft hat, welche Vorfälle gerade laufen samt Links auf ihre öffentlichen Darstellungen, und die Dienste mit Verfügbarkeitsbalken, letztem Prüfzeitpunkt und einem Runbook-Link pro Dienst. Nichts davon erscheint auf der öffentlichen Seite; das wird mit einer Whitelist und zwei Tests durchgesetzt und nicht mit einem Filter, an den jemand denken muss.

Ja, und genau darum geht es. Jeder Vorfall hat eine eigene dauerhafte URL, ein Link, den du in ein Ticket oder einen Chat kopiert hast, landet also weiterhin bei diesem Vorfall — was er betraf, wann er begann, wie lange er lief und jede Aktualisierung der Reihe nach — lange nachdem deine Statusseite aufgehört hat, davon zu sprechen. Er überlebt auch das Verlaufsfenster: das bestimmt, wie lang eine Liste sein soll, nicht wie lange ein Link funktionieren soll.

Ja. Zeige mit einem CNAME auf uns, und HTTPS wird automatisch besorgt und erneuert. Liegt der Hostname unter einer DNS-Zone, die du schon in InfraNest verwaltest, bei einem Anbieter mit Schreibzugriff, legt „Richte es für mich ein“ den Eintrag selbst an und startet die Prüfung — kein Umweg über den Registrar. Die Prüfung läuft im Hintergrund, und das Routing hinter der Domain wird bei jedem Deploy und stündlich als Sicherheitsnetz aus der Datenbank neu aufgebaut.

Wir speichern das Minimum. Anmeldungen sind Double Opt-in und unbestätigte werden nach Alter aufgeräumt; Admins sehen Zahlen und Statistiken ohne personenbezogene Daten; es gibt bewusst keinen Export der Abonnenten, mit einem Test, der das festhält; und „alle löschen“ löscht wirklich alle. Das sind Mitglieder der Öffentlichkeit, die um Ausfallmails über den Dienst eines anderen gebeten haben, die Latte liegt also höher als bei deiner eigenen Kontaktliste. Ein Abo pro Komponente gibt es ebenfalls nicht — alle auf einer Seite bekommen deren Meldungen, denn Abos pro Komponente vervielfachen die Bestätigungs- und Abmeldefläche für einen geringen Gewinn.

Auf zwei Wegen. Ein serverseitig gerendertes SVG-Badge, das du als Bild einbindest, das kein JavaScript braucht und deshalb in einem README, einer Doku-Seite, einem Footer oder einer E-Mail funktioniert. Und ein Live-Widget — ein cachebares Skript in einen Shadow Root, das alle sechzig Sekunden einen leichten Feed abfragt — in vier Layouts: Badge, Übersichtskarte, Liste pro Dienst und ein Banner, der sich ausblendet, wenn alles gesund ist. Es gibt außerdem ein Badge für einen einzelnen Monitor, unabhängig von jeder Seite, über einen nicht erratbaren Token adressiert, damit das Einschalten eines Badges die anderen nicht offenlegt.

Ja — eine Seite kann öffentlich oder passwortgeschützt für ein internes oder kundenspezifisches Publikum sein, mit einem eigenen Schalter dafür, ob Suchmaschinen sie indexieren dürfen. Das Passwort-Gate ist ein gemeinsames Stück Code, das Seite, Verlauf, Badge und Vorfallansicht alle benutzen, es gibt also keine Route, die still vergessen hat zu fragen. Eine geschützte Seite fragt das Passwort auch, bevor sie einen Vorfall benennt, damit der Titel nicht in einer Linkvorschau nach außen dringt.