Erfahren Sie, wie Sie eine SaaS-Statusseite mit Vorfallhistorie, klarer Kommunikation und Abonnements planen, erstellen und veröffentlichen, damit Kunden bei Ausfällen informiert bleiben.
Eine SaaS-Statusseite ist eine öffentliche (oder nur für Kunden zugängliche) Website, die zeigt, ob Ihr Produkt gerade funktioniert — und was Sie tun, wenn das nicht der Fall ist. Sie wird zur einzigen Quelle der Wahrheit während Vorfällen, getrennt von Social Media, Support-Tickets und Gerüchten.
Sie hilft mehr Menschen, als Sie vielleicht erwarten:
Eine gute Service-Status-Website enthält normalerweise drei verwandte (aber unterschiedliche) Ebenen:
Das Ziel ist Klarheit: Echtzeit-Status beantwortet „Kann ich das Produkt nutzen?“, die Historie beantwortet „Wie oft passiert das?“, und Postmortems beantworten „Warum ist das passiert und was hat sich geändert?"
Eine Statusseite funktioniert, wenn Updates schnell, in einfachem Sprachstil und ehrlich über den Umfang sind. Sie brauchen keine perfekte Diagnose, um zu kommunizieren. Sie brauchen Zeitstempel, Umfang (wer ist betroffen) und die Zeit des nächsten Updates.
Sie werden die Seite während Ausfällen, degradierter Leistung (langsame Logins, verzögerte Webhooks) und geplanter Wartung, die kurzzeitige Unterbrechungen verursachen kann, verwenden.
Wenn Sie die Statusseite als Produktfläche behandeln (nicht als einmalige Ops-Seite), wird der Rest der Einrichtung viel einfacher: Sie können Eigentümer definieren, Vorlagen erstellen und Monitoring verbinden, ohne den Prozess bei jedem Vorfall neu erfinden zu müssen.
Bevor Sie ein Tool wählen oder ein Layout entwerfen, entscheiden Sie, was Ihre Statusseite erreichen soll. Ein klares Ziel und ein klarer Eigentümer halten Statusseiten während eines Vorfalls nützlich — wenn alle beschäftigt sind und Informationen chaotisch sind.
Die meisten SaaS-Teams erstellen eine Statusseite für drei praktische Ergebnisse:
Schreiben Sie 2–3 messbare Signale auf, die Sie nach dem Start verfolgen können: weniger doppelte Tickets bei Ausfällen, schnellere Zeit bis zum ersten Update oder mehr Kunden, die Abonnements nutzen.
Ihr primärer Leser ist meist ein nicht-technischer Kunde, der wissen möchte:
Das bedeutet: Minimieren Sie Fachjargon. Bevorzugen Sie „Einige Kunden können sich nicht anmelden“ statt „Erhöhte 5xx-Raten auf Auth“. Falls technische Details nötig sind, halten Sie sie als kurze sekundäre Erklärung.
Wählen Sie einen Ton, den Sie unter Druck beibehalten können: ruhig, sachlich und transparent. Entscheiden Sie im Voraus:
Machen Sie die Verantwortung explizit: Die Statusseite sollte nicht „Jedermanns Aufgabe“ sein, sonst wird sie niemandes Aufgabe.
Sie haben zwei gängige Optionen:
Wenn Ihre Haupt-App ausfallen kann, ist eine eigenständige Statusseite meist sicherer. Sie können trotzdem prominent von Ihrer App und Ihrem Help-Center darauf verlinken (z. B. /help).
Eine Statusseite ist nur so nützlich wie die „Karte“, die dahintersteht. Bevor Sie Farben wählen oder Texte schreiben, entscheiden Sie, worüber Sie tatsächlich berichten. Ziel ist es, widerzuspiegeln, wie Kunden Ihr Produkt erleben — nicht, wie Ihre Organisationsstruktur aussieht.
Listen Sie die Teile auf, die ein Kunde meinen könnte, wenn er sagt „es ist kaputt“. Für viele SaaS-Produkte ist ein praktischer Ausgangspunkt:
Wenn Sie mehrere Regionen oder Tiers anbieten, erfassen Sie das ebenfalls (z. B. „API – US“ und „API – EU“). Wählen Sie für Kunden verständliche Namen: „Login“ ist klarer als „IdP Gateway".
Wählen Sie eine Gruppierung, die der Denkweise der Kunden entspricht:
Vermeiden Sie eine endlose Liste. Wenn Sie Dutzende Integrationen haben, überlegen Sie, eine übergeordnete Komponente („Integrationen") plus einige besonders wichtige Kinder (z. B. „Salesforce“, „Webhooks") anzuzeigen.
Ein einfaches, konsistentes Modell verhindert Verwirrung während Vorfällen. Gängige Stufen sind:
Schreiben Sie interne Kriterien für jede Stufe (auch wenn Sie diese nicht veröffentlichen). Zum Beispiel: „Partial Outage = eine Region ausgefallen“ oder „Degraded = p95-Latenz über X für Y Minuten“. Konsistenz schafft Vertrauen.
Die meisten Ausfälle involvieren Drittanbieter: Cloud-Hosting, E-Mail-Zustellung, Zahlungsdienstleister oder Identitätsanbieter. Dokumentieren Sie diese Abhängigkeiten, damit Ihre Incident-Updates korrekt sind.
Ob Sie diese öffentlich anzeigen, hängt vom Publikum ab. Wenn Kunden direkt betroffen sein können (z. B. Zahlungen), kann das Anzeigen einer Abhängigkeitskomponente hilfreich sein. Wenn es nur Rauschen erzeugt oder Schuldzuweisungen fördert, halten Sie Abhängigkeiten intern, verweisen Sie aber in Updates bei Bedarf darauf (z. B. „Wir untersuchen erhöhte Fehler beim Zahlungsanbieter").
Sobald Sie dieses Komponentenmodell haben, wird der Rest der Einrichtung viel einfacher: Jeder Vorfall hat von Anfang an ein klares „wo" (Komponente) und „wie schlimm" (Status).
Eine Statusseite ist am nützlichsten, wenn sie Kundenfragen in Sekunden beantwortet. Besucher sind oft gestresst und wollen Klarheit — keine umfangreiche Navigation.
Priorisieren Sie das Wesentliche oben:
Schreiben Sie in klarer Sprache. „Erhöhte Fehlerrate bei API-Anfragen" ist klarer als „Partial outage in upstream dependency". Wenn technische Begriffe nötig sind, fügen Sie eine kurze Übersetzung hinzu („Einige Anfragen können fehlschlagen oder timeouts erzeugen").
Ein verlässliches Muster ist:
Für die Komponentenliste behalten Sie kundenfreundliche Bezeichnungen. Wenn Ihr interner Service „k8s-cluster-2" heißt, brauchen Kunden vermutlich „API" oder „Background Jobs".
Machen Sie die Seite in Stresssituationen lesbar:
Platzieren Sie eine kleine Linkgruppe in der Nähe des Tops (Header oder direkt unter dem Banner):
Ziel ist Vertrauen: Kunden sollten sofort verstehen, was passiert, was betroffen ist und wann sie wieder von Ihnen hören.
Wenn ein Vorfall eintritt, jongliert Ihr Team mit Diagnose, Behebung und Kundenfragen gleichzeitig. Vorlagen nehmen die Unsicherheit weg, sodass Updates konsistent, klar und schnell bleiben — besonders wenn verschiedene Personen posten.
Ein gutes Update beginnt jedes Mal mit denselben Kerninformationen. Mindestens standardisieren Sie diese Felder, damit Kunden schnell erfassen, was los ist:
Wenn Sie eine Vorfallhistorie veröffentlichen, macht die Konsistenz dieser Felder vergangene Vorfälle leicht vergleichbar.
Zielen Sie auf kurze Updates, die stets dieselben Fragen beantworten. Hier eine praktische Vorlage, die Sie in Ihr Status-Tool kopieren können:
Title: Kurz und präzise (z. B. „API-Fehler in EU-Region")
Start time: YYYY-MM-DD HH:MM (TZ)
Affected components: API, Dashboard, Payments
Impact: Was Nutzer sehen (Fehler, Timeouts, degradierte Performance) und wer betroffen ist
What we know: Ein Satz zur Ursache falls bestätigt (keine Spekulationen)
What we’re doing: Konkrete Maßnahmen (Rollback, Skalierung, Vendor-Eskalation)
Next update: Zeit des nächsten geplanten Updates
Updates:
Kunden wollen nicht nur Informationen — sie wollen Vorhersehbarkeit.
Geplante Wartung sollte ruhig und strukturiert wirken. Standardisieren Sie Wartungsbeiträge mit:
Halten Sie die Sprache spezifisch (was sich ändert, was Nutzer bemerken könnten) und versprechen Sie nicht zu viel — Kunden schätzen Genauigkeit mehr als Optimismus.
Eine Vorfallhistorie ist mehr als ein Log — sie ermöglicht Kunden (und Ihrem Team), schnell zu verstehen, wie oft Probleme auftreten, welche Arten von Problemen sich wiederholen und wie Sie reagieren.
Eine klare Historie schafft Vertrauen durch Transparenz. Sie erzeugt auch Trend-Sichtbarkeit: Wiederkehrende „API-Latenz“-Vorfälle alle paar Wochen signalisieren, dass in Performance investiert werden sollte (und priorisieren Post-Incident-Reviews). Konsistente Berichterstattung reduziert langfristig Support-Tickets, weil Kunden Antworten selbst finden.
Wählen Sie eine Retentions-Periode, die zu Kundenerwartungen und Produktreife passt.
Was auch immer Sie wählen, geben Sie es klar an (z. B. „Vorfallhistorie wird 12 Monate aufbewahrt").
Konsistenz erleichtert das Scannen. Verwenden Sie ein vorhersehbares Namensformat wie:
YYYY-MM-DD — Kurze Zusammenfassung (z. B. „2025-10-14 — Verzögerte E-Mail-Zustellung")
Zeigen Sie für jeden Vorfall mindestens:
Wenn Sie Postmortems veröffentlichen, verlinken Sie von der Vorfalldetailseite zum Bericht (z. B. „Read the postmortem" verlinkt zu /blog/postmortems/2025-10-14-email-delays). So bleibt die Timeline übersichtlich, während interessierte Kunden Details finden.
Eine Statusseite hilft nur, wenn Kunden daran denken, sie zu prüfen. Abonnements kehren das um: Kunden erhalten Updates automatisch, ohne die Seite zu aktualisieren oder den Support zu fragen.
Die meisten Teams bieten mindestens ein paar Optionen an:
Wenn Sie mehrere Kanäle unterstützen, gestalten Sie den Setup-Prozess konsistent, damit sich Kunden nicht fühlen, als müssten sie vier verschiedene Anmeldungen durchführen.
Abonnements sollten immer opt-in sein. Machen Sie deutlich, was Nutzer erhalten, bevor sie bestätigen — besonders bei SMS.
Geben Sie Abonnenten Kontrolle über:
Diese Präferenzen reduzieren Alert-Fatigue und halten Ihre Benachrichtigungen vertrauenswürdig. Falls Sie noch keine komponentenspezifischen Abos haben, starten Sie mit „Alle Updates" und fügen Filter später hinzu.
Während eines Vorfalls steigt die Nachrichtenmenge und Drittanbieter können Traffic drosseln. Prüfen Sie:
Es lohnt sich, regelmäßige Tests (z. B. quartalsweise) durchzuführen, um sicherzustellen, dass Abonnements wie erwartet funktionieren.
Fügen Sie einen deutlichen Callout auf der Status-Homepage hinzu — möglichst above the fold — damit Kunden sich vor dem nächsten Vorfall anmelden können. Machen Sie ihn auf Mobilgeräten sichtbar und verlinken Sie ihn an Stellen, an denen Kunden Hilfe suchen (z. B. im Support-Portal oder /help Center).
Die Entscheidung, wie Sie Ihre Statusseite bauen, geht weniger um „Können wir es bauen?“ und mehr darum, worauf Sie optimieren möchten: Zeit bis zum Launch, Zuverlässigkeit bei Vorfällen und laufender Wartungsaufwand.
Ein gehostetes Tool ist meist der schnellste Weg. Sie erhalten eine fertige Statusseite, Abonnements, Vorfallszeitleisten und oft Integrationen mit gängigen Monitoring-Systemen.
Worauf Sie bei einem gehosteten Tool achten sollten:
DIY kann sinnvoll sein, wenn Sie volle Kontrolle über Design, Datenaufbewahrung und Vorfallhistorie haben möchten. Der Kompromiss ist, dass Sie für Zuverlässigkeit und Betrieb verantwortlich sind.
Eine praktikable DIY-Architektur ist:
Planen Sie Ausfallfälle ein: Was passiert, wenn Ihre Primärdatenbank nicht verfügbar ist oder Ihre Deploy-Pipeline ausfällt? Viele Teams hosten die Statusseite auf separater Infrastruktur (oder sogar bei einem anderen Anbieter) als das Hauptprodukt.
Wenn Sie die Kontrolle von DIY wollen, aber nicht alles neu bauen möchten, kann eine Chat-gesteuerte Plattform wie Koder.ai helfen, schnell eine maßgeschneiderte Statusseite (Web-UI plus kleine Incident-API) aus einer Spezifikation zu erstellen. Das ist nützlich für Teams, die ein spezifisches Komponentenmodell, individuelles Vorfallhistorie-UX oder interne Admin-Workflows möchten — und trotzdem den Quellcode exportieren, deployen und schnell iterieren wollen.
Gehostete Tools haben oft vorhersehbare monatliche Preise; DIY hat Engineering-Zeit, Hosting-/CDN-Kosten und laufenden Wartungsaufwand. Wenn Sie Optionen vergleichen, legen Sie die erwarteten monatlichen Kosten und die interne Zeit fest — und prüfen Sie das gegen Ihr Budget (siehe /pricing).
Eine Statusseite ist nur nützlich, wenn sie die Realität schnell widerspiegelt. Der einfachste Weg ist, die Systeme, die Probleme erkennen (Monitoring), mit denen zu verbinden, die Ihre Reaktion koordinieren (Incident-Workflow), damit Updates konsistent und zeitnah sind.
Die meisten Teams kombinieren drei Datenquellen:
Eine praktische Regel: Monitoring erkennt; Incident-Workflow koordiniert; die Statusseite kommuniziert.
Automatisierung spart Minuten, wenn es zählt:
Halten Sie die erste öffentliche Nachricht konservativ. „Untersuchung erhöhter Fehlerraten" ist sicherer als „Ausfall bestätigt", wenn Sie noch validieren.
Vollautomatische Nachrichten können nach hinten losgehen:
Nutzen Sie Automatisierung, um Entwürfe und Vorschläge zu erstellen, verlangen Sie aber eine menschliche Freigabe für kundenseitige Formulierungen — besonders für Zustände wie Identified, Mitigated und Resolved.
Behandeln Sie die Statusseite wie ein kundenorientiertes Logbuch. Stellen Sie sicher, dass Sie beantworten können:
Dieser Audit-Trail hilft bei Post-Incident-Reviews, reduziert Verwirrung bei Übergaben und schafft Vertrauen, wenn Kunden Klarstellungen wünschen.
Eine Statusseite hilft nur, wenn sie erreichbar ist, während Ihr Produkt nicht erreichbar ist. Der häufigste Fehler ist, die Statusseite auf derselben Infrastruktur wie die App zu hosten — wenn die App ausfällt, verschwindet auch die Statusseite und Kunden haben keine Quelle der Wahrheit mehr.
Hosten Sie die Statusseite wenn möglich bei einem anderen Anbieter als Ihre Produktions-App (oder zumindest in einem anderen Account/Region). Ziel ist es, die Blast-Radius-Separation zu reduzieren: Ein Ausfall auf Ihrer App-Plattform sollte nicht gleichzeitig Ihre Kommunikationskanäle lahmlegen.
Überlegen Sie außerdem, DNS zu trennen. Wenn die DNS der Hauptdomain im selben Ort wie Ihr App-Edge/CDN verwaltet wird, kann ein DNS- oder Zertifikatsproblem beide blockieren. Viele Teams verwenden eine eigene Subdomain (z. B. status.ihrefirma.com) mit separat gehostetem DNS.
Halten Sie Assets leichtgewichtig: minimales JavaScript, komprimiertes CSS und keine Abhängigkeiten, die die APIs Ihrer App zum Rendern benötigen. Legen Sie ein CDN vor die Statusseite und aktivieren Sie Caching für statische Ressourcen, sodass sie auch bei hohem Traffic lädt.
Ein praktisches Sicherheitsnetz ist ein Fallback-Static-Modus:
Kunden sollten sich nicht einloggen müssen, um die Service-Gesundheit zu sehen. Halten Sie die Statusseite öffentlich, aber legen Sie Admin-/Editor-Tools hinter Authentifizierung (SSO, falls vorhanden) mit starken Zugriffsregeln und Audit-Logs.
Testen Sie schließlich Ausfallszenarien: Sperren Sie in einer Staging-Umgebung vorübergehend Ihren App-Origin und prüfen Sie, ob die Statusseite weiterhin aufgelöst wird, schnell lädt und aktualisiert werden kann, wenn Sie sie am dringendsten benötigen.
Eine Statusseite baut nur Vertrauen auf, wenn sie während echter Vorfälle konsistent aktualisiert wird. Diese Konsistenz entsteht nicht zufällig — Sie brauchen klare Verantwortung, einfache Regeln und eine vorhersehbare Kadenz.
Halten Sie das Kernteam klein und explizit:
Bei kleinen Teams kann eine Person zwei Rollen übernehmen — entscheiden Sie das im Voraus. Dokumentieren Sie Rollenhandoffs und Eskalationswege im On-Call-Handbuch (siehe /docs/on-call).
Wenn ein Alert zu einem kundenrelevanten Vorfall wird, folgen Sie einem wiederholbaren Ablauf:
Eine praktische Regel: posten Sie das erste Update innerhalb von 10–15 Minuten, dann alle 30–60 Minuten solange der Impact besteht — auch wenn die Botschaft lautet „Kein Fortschritt, wir untersuchen weiterhin."
Führen Sie innerhalb von 1–3 Arbeitstagen ein leichtes Post-Incident-Review durch:
Aktualisieren Sie dann den Vorfall-Eintrag mit der finalen Zusammenfassung, damit Ihre Vorfallhistorie nützlich bleibt — nicht nur ein Log von „resolved"-Nachrichten.
Eine Statusseite ist nur nützlich, wenn sie leicht zu finden, vertrauenswürdig und konsequent aktuell ist. Bevor Sie sie ankündigen, führen Sie einen kurzen „production-ready"-Check durch — und legen Sie danach eine leichte Routine zur Verbesserung fest.
Text und Struktur
Branding und Vertrauen
Zugriff und Berechtigungen
Workflow testen
Ankündigen
Wenn Sie eine eigene Statusseite bauen, führen Sie dieselbe Checkliste zunächst in einer Staging-Umgebung durch. Tools wie Koder.ai können diesen Iterationszyklus beschleunigen, indem sie UI, Admin-Screens und Backend-Endpunkte aus einem einzigen Spec generieren — und Ihnen dann erlauben, den Code zu exportieren und überall zu deployen.
Verfolgen Sie einige einfache Kennzahlen und prüfen Sie sie monatlich:
Führen Sie eine grundlegende Taxonomie, damit die Historie handlungsfähig wird:
Im Laufe der Zeit addieren sich kleine Verbesserungen — klarere Formulierungen, schnellere Updates, bessere Kategorisierung — zu weniger Unterbrechungen, weniger Tickets und mehr Kundenvertrauen.
Eine SaaS-Statusseite ist eine dedizierte Seite, die aktuelle Service-Gesundheit und Vorfallsupdates an einem einzigen kanonischen Ort anzeigt. Sie ist wichtig, weil sie die Frage „Ist es down?“ reduziert, Erwartungen während Ausfällen setzt und Vertrauen durch klare, mit Zeitstempel versehene Kommunikation aufbaut.
Der Echtzeit-Status beantwortet „Kann ich das Produkt gerade benutzen?“ mit komponentenspezifischen Zuständen.
Die Vorfallhistorie beantwortet „Wie oft passiert das?“ mit einer Zeitleiste vergangener Vorfälle und Wartungen.
Postmortems beantworten „Warum ist das passiert und was hat sich geändert?“ mit Ursachenanalyse und Präventionsmaßnahmen (oft von der Vorfallseite verlinkt).
Beginnen Sie mit 2–3 messbaren Ergebnissen:
Schreiben Sie diese Ziele auf und überprüfen Sie sie monatlich, damit die Seite nicht veraltet.
Weisen Sie eine explizite verantwortliche Person und eine Vertretung zu (häufig die on-call Rotation). Viele Teams verwenden:
Definieren Sie außerdem im Voraus Regeln: wer veröffentlichen darf, ob Genehmigungen nötig sind und die minimale Update-Frequenz (z. B. alle 30–60 Minuten bei großen Vorfällen).
Wählen Sie Komponenten basierend darauf, wie Kunden Probleme beschreiben — nicht anhand interner Servicenamen. Gängige Komponenten sind:
Wenn die Zuverlässigkeit geografisch variiert, teilen Sie nach Regionen (z. B. „API – US“ und „API – EU“).
Verwenden Sie eine kleine, konsistente Menge an Statusstufen und dokumentieren Sie interne Kriterien für jede Stufe:
Konsistenz ist wichtiger als perfekte Präzision. Kunden sollten durch wiederholte, vorhersehbare Nutzung lernen, was jede Stufe bedeutet.
Ein praktisches Vorfalls-Update sollte immer enthalten:
Auch wenn die Ursache noch unbekannt ist, können Sie Umfang, Auswirkungen und die nächsten Schritte kommunizieren.
Posten Sie schnell ein erstes „Investigating“-Update (oft innerhalb von 10–15 Minuten nach bestätigtem Impact). Dann:
Wenn Sie Ihre Frequenz nicht einhalten können, posten Sie eine kurze Mitteilung zur Anpassung der Erwartungen, anstatt still zu bleiben.
Hosted-Tools sind auf Geschwindigkeit und Zuverlässigkeit optimiert (bleiben oft erreichbar, selbst wenn Ihre App ausfällt) und beinhalten meist Abonnements und Integrationen.
DIY gibt volle Kontrolle, erfordert aber Ausfallsicherheit:
Bieten Sie die Kanäle an, die Kunden ohnehin nutzen (typischerweise E-Mail und SMS, plus Slack/Teams oder RSS). Halten Sie Abonnements opt-in und machen Sie deutlich:
Testen Sie Zustellbarkeit und Rate-Limits regelmäßig, damit Benachrichtigungen auch bei Traffic-Spitzen funktionieren.
