SaaS-Statusseiten richtig lesen: Was ein Incident wirklich bedeutet

Für kleine Teams ist deshalb eine einfache Trennung hilfreich:

• Statusseite: Was bestätigt der Anbieter öffentlich?
• Eigene Prüfung: Was sehen die eigenen Nutzer, Konten und Integrationen?
• Vertrag: Welche Verfügbarkeit und welche Folgen sind tatsächlich zugesagt?

Wer diese drei Ebenen trennt, reagiert bei einer Störung ruhiger und vermeidet zwei typische Fehler: zu früh an der eigenen Konfiguration zu ändern oder zu lange auf eine allgemeine Entwarnung zu warten.

Zuerst die betroffene Komponente prüfen

Die große Ampel am Seitenkopf ist nur eine Zusammenfassung. Entscheidend ist, ob die konkrete Funktion betroffen ist, die Ihr Team gerade benötigt: Anmeldung, API, Dateiupload, Abrechnung oder eine bestimmte Region. Atlassian unterscheidet dafür Komponenten und Zustände wie „Degraded Performance“, „Partial Outage“ und „Major Outage“. Ein Dienst kann insgesamt erreichbar sein, während eine einzelne Funktion langsam oder für einen Teil der Kunden nicht verfügbar ist.

Fragen Sie deshalb nicht nur „Ist der Anbieter down?“, sondern:

1. Welche Funktion scheitert bei uns?
2. Ist genau diese Komponente auf der Statusseite genannt?
3. Stimmen Region, Kontoart und Zeitpunkt überein?
4. Funktioniert ein unabhängiger Kontrollweg, etwa Web-App statt API?

Wenn Sie zuerst eigene Fehler sichtbar machen möchten, ergänzt der Saaspective-Artikel Fehler früher sehen: Einfache Tools für kleine Teams diese Einordnung um Monitoring, Logs und Uptime-Checks.

Incident-Phasen richtig einordnen

Atlassian nennt für Incidents vier Phasen: Investigating, Identified, Monitoring und Resolved. Diese Begriffe sind keine Garantie für einen festen Zeitplan. Sie zeigen, wie weit die offizielle Kommunikation fortgeschritten ist.

Investigating: Das Problem ist bestätigt, die Ursache noch offen

In dieser Phase sollte Ihr Team Beobachtungen sammeln, statt Vermutungen als Fakten weiterzugeben. Notieren Sie die genaue Fehlermeldung, den ersten beobachteten Zeitpunkt, betroffene Nutzer und fehlgeschlagene Arbeitsabläufe. Vermeiden Sie irreversible Änderungen, solange nicht klar ist, ob die eigene Konfiguration beteiligt ist.

Identified: Der Anbieter nennt eine Ursache oder einen betroffenen Bereich

„Identified“ bedeutet noch nicht, dass die Lösung bereits wirkt. Prüfen Sie, ob die genannte Komponente und Region zu Ihrem Fall passen. Wenn der Anbieter einen Workaround nennt, sollte er zunächst mit einem risikoarmen Vorgang getestet werden.

Monitoring: Eine Maßnahme ist aktiv, Rückfälle bleiben möglich

Bei „Monitoring“ ist eine Reparatur oder Gegenmaßnahme typischerweise umgesetzt, wird aber noch beobachtet. Starten Sie kritische Sammelverarbeitung nicht sofort in voller Größe. Ein kleiner kontrollierter Test zeigt, ob Anmeldung, Schreiben, Export und Integrationen in Ihrem konkreten Konto wieder stabil arbeiten.

Resolved: Die offizielle Störung ist beendet

„Resolved“ beendet die Anbietermeldung, nicht automatisch Ihre interne Prüfung. Kontrollieren Sie fehlgeschlagene Jobs, Webhooks, Importe, Zahlungen oder Benachrichtigungen. Manche Vorgänge werden nicht automatisch nachgeholt.

Öffentliche Statusseite und eigenes Konto sind nicht dasselbe

Große Cloud-Anbieter machen diese Grenze deutlich. Die öffentliche AWS Health Service-Ansicht zeigt allgemeine Service-Ereignisse; angemeldete Kunden erhalten zusätzlich kontobezogene Informationen. Microsoft beschreibt die öffentliche Azure-Statusseite als globale Sicht und empfiehlt Service Health für Ereignisse, Wartung und Hinweise, die zu Abonnements und Regionen passen.

Für SaaS-Kunden folgt daraus: Eine grüne öffentliche Seite widerlegt Ihr Problem nicht. Umgekehrt muss ein rotes globales Ereignis nicht jeden Arbeitsablauf treffen. Speichern Sie deshalb neben dem Statuslink auch Konto, Region, betroffene Funktion und eigene Zeitstempel.

Uptime, SLO und SLA nicht vermischen

Google SRE trennt drei Begriffe:

• Ein SLI ist eine gemessene Kenngröße, etwa erfolgreiche Anfragen oder Latenz.
• Ein SLO ist ein Zielwert für eine solche Kenngröße.
• Ein SLA ist eine Vereinbarung, die Folgen für das Verfehlen eines Ziels festlegt.

Eine Statusseite dokumentiert Ereignisse, ersetzt aber nicht den Vertrag und seine Messmethode. Für eine mögliche Gutschrift oder Eskalation zählen die konkrete SLA-Fassung, der Messzeitraum, Ausschlüsse und das vorgeschriebene Verfahren. Leiten Sie aus einer roten Ampel allein keinen Anspruch ab und lassen Sie Vertragsfragen im Zweifel fachlich prüfen.

Eine kurze Erstprüfung für kleine Teams

Beobachtung festhalten

Schreiben Sie eine sachliche Ein-Zeilen-Beschreibung: „Anmeldung für drei Teammitglieder schlägt seit dem beobachteten Zeitpunkt fehl.“ Trennen Sie Beobachtung und Vermutung. Das verhindert, dass aus „Login scheitert“ vorschnell „der Anbieter hat Daten verloren“ wird.

Offizielle Meldung zuordnen

Öffnen Sie die Statusseite über ein gespeichertes Lesezeichen, nicht über einen Link aus einer unerwarteten Nachricht. Prüfen Sie Incident, Komponente, Region und letzten Aktualisierungszeitpunkt. Abonnieren Sie Updates, wenn der Anbieter dies anbietet.

Eigene Reichweite bestimmen

Testen Sie einen risikoarmen Kontrollvorgang. Sind alle Nutzer betroffen oder nur einzelne Rollen? Betrifft es Web-App, API oder Integration? Gab es unmittelbar vorher eine interne Änderung? Diese Fragen helfen, Anbieterproblem und lokales Problem auseinanderzuhalten.

Geschäftsauswirkung begrenzen

Entscheiden Sie anhand des Arbeitsablaufs: Kann das Team lesen, aber nicht schreiben? Müssen Eingaben vorübergehend lokal dokumentiert werden? Gibt es einen freigegebenen Ersatzkanal? Vermeiden Sie spontane Schattenlösungen, die später Datenschutz-, Zugriffs- oder Synchronisationsprobleme erzeugen.

Nach der Entwarnung kontrollieren

Prüfen Sie Warteschlangen, Automationen und Integrationen auf Lücken. Dokumentieren Sie, was manuell nachgeholt wurde. Bei wiederkehrenden Vorfällen lohnt sich eine einfache Abhängigkeitsliste: Welcher Geschäftsprozess hängt von welchem Dienst ab, wer entscheidet über den Ersatzweg und wo liegen Exporte oder Notfallkontakte?

Was eine gute Statushistorie verrät

Ein einzelner Incident sagt wenig über die langfristige Zuverlässigkeit. Nützlicher sind wiederkehrende Muster: Welche Komponenten fallen auf, wie konkret sind Updates, gibt es nach größeren Vorfällen nachvollziehbare Rückblicke und passen die gemeldeten Auswirkungen zu Ihren Beobachtungen? Nutzen Sie diese Historie als Gesprächsgrundlage für Risiko und Beschaffung, nicht als alleinige Rangliste.

Fazit

Eine Statusseite beantwortet eine begrenzte, aber wichtige Frage: Was kommuniziert der Anbieter gerade offiziell? Für eine belastbare Entscheidung braucht Ihr Team zusätzlich eigene Beobachtungen und den konkreten Vertrag. Prüfen Sie zuerst die betroffene Komponente, lesen Sie die Incident-Phase als Zwischenstand, begrenzen Sie die Geschäftsauswirkung und kontrollieren Sie nach der Entwarnung offene Vorgänge. So wird aus einer farbigen Ampel ein ruhiger, nachvollziehbarer Arbeitsablauf.