Platform Health und öffentlicher Status: Grün heißt etwas
Wie Readiness Checks, das Admin-Health-Cockpit, Job Runs und der öffentliche Status verhindern, dass aus Incidents Folklore wird.
Health Checks sind nicht glamourös. Das ist ihr Charme. Sie sagen Platform Staff, ob App, Datenbank, Auth, Storage, Mail, Notification Queue, Cron, Webhooks, öffentliche API, Billing, der externe Secret Store, das Activity Audit und die Observability sich gut genug für normales Arbeiten verhalten. Dreizehn Komponenten, je eine Frage: Tut dieses Ding gerade seinen Job?
/api/health
Der technische Health-Endpoint liefert die App Readiness mit Komponentenprüfungen, Latenz und bereinigtem Status. Er ist für Uptime-Monitoring und Deploy-Smoke-Checks gebaut, nicht dafür, Datenbankdetails ins Internet zu lassen.
Das Plattform-Cockpit
/admin/platform/health ist die Incident-Konsole für Platform Owner und Staff; Platform Viewer sehen den Sidebar-Eintrag nicht und werden umgeleitet, wenn sie die Adresse öffnen, und Organisations-Admins können sie gar nicht öffnen. Sie zeigt den globalen Status, die Release Readiness, eine Support-Zusammenfassung, wahrscheinliche Ursachen, den Status je Abhängigkeit mit ihrer Kategorie — Plattform, Daten, extern, Tenant-Integration, Billing, Queue oder Evidence —, die Zahl der betroffenen Tenants, wo sich das sicher ableiten lässt, den letzten Check, den letzten Erfolg und den letzten Fehler sowie die jüngsten Job Runs. Cron-Routen und Background Jobs schreiben begrenzte Job-Run-Records, damit die Plattform beantworten kann, ob eine geplante Aufgabe gelaufen ist, gescheitert ist, blockiert war, teilweise lief oder still ein Nickerchen gemacht hat.
Worte statt Codes
Die Konsole spricht Supportsprache. Interne Severity-Codes sind durch Auswirkungs-Labels ersetzt — Dringender Ausfall, Hohe Auswirkung, Incident-Nachverfolgung, Prüfung mit niedriger Priorität — und zwei Zustände existieren genau dafür, dass niemand vor der falschen Karte in Panik gerät: „noch nicht konfiguriert“ heißt, dass eine Abhängigkeit bewusst fehlt oder keinen direkten Monitor hat, was kein Ausfall ist, und „konnte nicht geprüft werden“ heißt, dass die Seite die Quelldaten nicht lesen oder verifizieren konnte. Billing darf melden, dass Subscription Billing nicht konfiguriert ist, während die lokale Paketdurchsetzung weiterarbeitet. Jede Komponentenkarte verlinkt auf die passendste Admin-, Settings- oder Health-Seite. Öffnet der Support während eines Incidents ein Ticket, kann ein Snapshot dieses Kontexts automatisch an das Ticket gehängt werden.
Öffentlicher Status
/api/status/public stellt einen bereinigten Komponenten-Feed für eine Statusseite oder einen externen Monitor bereit. Er kann sagen, dass File Storage oder geplante Jobs degradiert sind, ohne Tenant-Namen, Payloads, Secrets oder Stack Traces preiszugeben. Transparenz ist gut; zu viel preisgeben bleibt trotzdem zu viel preisgeben.
Warum das zählt
Wenn etwas nicht stimmt, braucht der Support eine gemeinsame Quelle der Wahrheit. Health macht aus „liegt das nur an mir?“ ein „Storage ist degradiert, Uploads sind betroffen, alles andere ist in Ordnung“. Dieser Satz spart erstaunlich viel Sauerstoff.