Eine Status-Page, die kein 29-$-pro-Monat-Abo ist

Eine Status-Page ist eines dieser Dinge, die fast reflexhaft als SaaS-Abo gekauft werden, weil es historisch bedeutete, einen ganzen separaten Monitoring-Dienst zu betreiben, nur um “ist es für alle down oder nur für mich” zu beantworten. Railyards Version existiert, weil die Plattform schon Uptime-Checks auf jeder App ausführt, die sie hostet — die Status-Page ist eine Ansicht auf Daten, die schon existieren, kein neues System, das aufgesetzt werden muss.

Was sie tatsächlich zeigt

Erstelle eine über Status pages in der Sidebar (nur Admins): einen Titel, eine Adresse (https://app.railyard.run/status/<adresse>), und welche Apps einbezogen werden, jede mit ihrem eigenen kundenseitigen Namen — Kunden sehen “API” und “Dashboard”, nie deine internen App-Slugs.

Besucher bekommen:

• Ein Gesamtbanner — operational, degraded, partial outage oder major outage, aggregiert über alle Apps der Seite.
• Eine Zeile pro App mit ihrem Live-Status: operational, degraded (2 oder mehr der letzten 5 Checks fehlgeschlagen), down, under maintenance, oder sleeping.
• 90 Tage tägliche Uptime-Balken und den Prozentsatz, aus denselben Checks gebaut, die Railyard schon ausführt — kein separater Ping-Dienst mit eigener False-Positive-Rate, die nachjustiert werden muss.
• Aktuelle und jüngste Incidents, die letzten 14 Tage davon.

Die Seite aktualisiert sich jede Minute und folgt der Hell-/Dunkel-Präferenz des Besuchers. Ein /status/<adresse>.json-Endpunkt liefert dieselben Daten — Status, 90-Tage-Uptime, offene Incidents — für alles, was du selbst darauf aufbauen willst.

Incidents, die niemand sich merken muss zu schließen

Das ist das Detail, das mehr zählt als die Uptime-Balken: Incidents öffnen und lösen sich selbst, gekoppelt an dieselben Checks — wenn eine App ausfällt, öffnet sich ein Incident; wenn sie wiederkommt, spiegelt der Incident das, ohne dass sich ein Mensch einloggen und ein Statusfeld aktualisieren muss. Du kannst weiterhin eigene Incidents von Hand posten (Titel, Impact-Level, ein Status, ein erstes Update, das Besucher sehen, und weitere Updates, während sich Dinge ändern), was für die Fälle zählt, die Automatisierung nicht wissen kann — eine beeinträchtigte Drittanbieter-Abhängigkeit, ein geplantes Maintenance-Fenster — aber der Grundfall “es fiel aus und kam zurück” braucht null manuelles Eingreifen.

Was sie ehrlich noch nicht leistet

Zwei echte Grenzen, klar benannt statt später entdeckt: Die Seite lebt auf Railyards eigener Adresse, sie kann noch nicht auf deiner eigenen Domain ausgeliefert werden. Und ihre Daten kommen ausschließlich aus Uptime-Checks gegen die Web-Adressen deiner Apps — eine reine Worker-App ohne etwas, das auf einem Port lauscht, hat nichts zu prüfen, also auch keine sinnvolle Zeile auf einer Status-Page.

Warum das kleiner ist, als es aussieht

Das eigentliche Engineering hinter einer Status-Page — Uptime-Historie, Incident-Zustandsautomaten, eine öffentliche Read-only-Ansicht — muss schon existieren, damit das eigene Monitoring und Alerting der Plattform funktioniert. Eine dedizierte Status-Page-SaaS verkauft Zugriff auf Daten, die eine PaaS über deine Apps schon sammelt; hier ist die Seite genau diese Daten, absichtlich öffentlich gemacht.

Vollständige Referenz: Status pages.