SaaS-Statusseiten richtig lesen: Was ein Incident wirklich bedeutet

Prüfen Sie in dieser Reihenfolge:

1. Was scheitert konkret? Zum Beispiel Anmeldung, API, Zahlung oder Dateiupload.
2. Passt die gemeldete Komponente? Achten Sie auch auf Region, Produkt und Tarif.
3. Wie aktuell ist das letzte Update? Ein alter Zeitstempel ist keine neue Entwarnung.
4. Lässt sich der Fehler kontrolliert wiederholen? Testen Sie mit einem zweiten Nutzer, Gerät oder Zugangsweg, ohne Daten zu verändern.
5. Was ist jetzt die kleinste sichere Maßnahme? Warten, Ersatzweg aktivieren, Support informieren oder intern weiter prüfen.

Ich halte die große grüne oder rote Ampel für den falschen Startpunkt. Entscheidend ist der Geschäftsablauf, der bei Ihnen gerade funktioniert oder ausfällt. Eine Statusseite ist ein Kommunikationskanal – keine vollständige Diagnose.

Warum die Gesamtampel allein nicht reicht

Viele Statusseiten teilen einen Dienst in Komponenten auf: Web-App, API, Login, Upload, einzelne Regionen oder abhängige Dienste. Bei Atlassian Statuspage wird der Gesamtstatus aus den Zuständen dieser Komponenten berechnet. Schon deshalb kann oben eine zusammenfassende Meldung stehen, obwohl nur ein Teil des Produkts betroffen ist. Der Anbieter kann die Einstufung eines Incidents außerdem manuell anpassen.

Schauen Sie daher zuerst auf drei Details:

• die tatsächlich genutzte Komponente,
• die betroffene Region oder Kundengruppe,
• den Zeitpunkt des letzten Updates.

Das ist besonders wichtig bei „Partial Outage“. Laut Atlassians Erklärung der Komponentenstatus kann eine Funktion für eine Teilgruppe komplett ausfallen und für andere normal arbeiten. „Degraded Performance“ bedeutet dagegen, dass die Komponente noch arbeitet, aber langsamer oder eingeschränkt ist.

Was die fünf häufigen Komponentenstatus bedeuten

Die Bezeichnungen stammen aus Atlassian Statuspage und sind deshalb nicht bei jedem Anbieter identisch. Nutzen Sie die Tabelle als Leseschlüssel, nicht als universelle Garantie.

Incident-Phasen richtig lesen

Atlassian nennt vier verbreitete Phasen. Sie beschreiben den Stand der Kommunikation, nicht die Restdauer.

Investigating: bestätigt, aber noch nicht erklärt

Der Anbieter untersucht den Vorfall. Sammeln Sie jetzt Beobachtungen: genaue Fehlermeldung, erster bemerkter Zeitpunkt, betroffene Nutzer und fehlgeschlagener Ablauf. Ändern Sie nicht gleichzeitig Passwörter, Integrationen und Netzwerke – sonst ist später kaum erkennbar, was geholfen oder geschadet hat.

Identified: Ursache oder betroffener Bereich eingegrenzt

Der Anbieter hat die Ursache nach eigener Aussage gefunden oder zumindest eingegrenzt und arbeitet an einer Lösung. „Identified“ heißt nicht „behoben“. Ein vorgeschlagener Workaround sollte zuerst mit einem risikoarmen Vorgang getestet werden.

Monitoring: Maßnahme umgesetzt, Wirkung wird beobachtet

Atlassian beschreibt „Monitoring“ als Phase, in der ein Fix umgesetzt wurde und auf Wirkung geprüft wird. Starten Sie kritische Stapelverarbeitung trotzdem nicht sofort in voller Größe. Testen Sie zunächst Lesen, Schreiben, Export und Integrationen mit kleinen, kontrollierbaren Vorgängen.

Resolved: Anbieterseitig beendet, intern noch zu prüfen

„Resolved“ bedeutet in Atlassians Beschreibung, dass die geschäftliche Auswirkung beendet und das Problem gelöst ist. Für Ihr Team können dennoch Folgen offen sein: nicht zugestellte Webhooks, doppelte Zahlungen, fehlgeschlagene Importe oder liegen gebliebene Benachrichtigungen.

Öffentliche und persönliche Statusansicht unterscheiden

Eine öffentliche Statusseite zeigt oft nur breite Ereignisse. AWS Health empfiehlt angemeldeten Kunden die kontospezifische Ansicht. Microsoft beschreibt die öffentliche Azure-Statusseite als globale Sicht und Azure Service Health als personalisierte Ansicht für Abonnements und Regionen. Auch Google Cloud Personalized Service Health filtert Ereignisse, die für Projekte relevant sind.

Die praktische Folge: Eine grüne öffentliche Seite widerlegt Ihren Fehler nicht. Prüfen Sie – sofern vorhanden – zuerst die persönliche Health-Ansicht und danach Ihre eigenen Signale.

So reagieren kleine Teams ohne Aktionismus

1. Beobachtung und Vermutung trennen

Schreiben Sie: „Drei Nutzer können seit 10:14 Uhr keine Rechnungen exportieren.“ Schreiben Sie nicht: „Der Anbieter hat unsere Daten verloren.“ Der erste Satz ist prüfbar, der zweite eine unbelegte Vermutung.

2. Einen unabhängigen Kontrollweg nutzen

Testen Sie beispielsweise Web-App statt API, Mobilfunk statt Firmennetz oder einen zweiten Nutzer mit gleichen Rechten. Der Test sollte keine Daten löschen, Zahlungen auslösen oder große Wiederholungsjobs starten. Wer eigene Signale systematisch aufbauen möchte, findet im Beitrag Fehler mit einfachen Monitoring-Werkzeugen früher erkennen einen passenden Einstieg.

3. Die Geschäftsauswirkung benennen

„CRM langsam“ ist technisch, aber noch keine Priorität. „Der Vertrieb kann keine Angebote versenden“ zeigt, welcher Prozess blockiert ist. Entscheiden Sie danach, ob das Team warten kann, einen freigegebenen Ersatzweg braucht oder Kunden informieren muss.

4. Wiederholungen begrenzen

Bei Zeitüberschreitungen ist nicht immer klar, ob ein Auftrag doch verarbeitet wurde. Unkontrolliertes Klicken kann doppelte Bestellungen, Nachrichten oder Zahlungen erzeugen. Prüfen Sie zuerst, ob der Vorgang eine eindeutige ID oder einen sichtbaren Status hat.

5. Ein brauchbares Support-Ticket senden

Nennen Sie Produkt, Komponente, Region, Konto, Beginn, letzte erfolgreiche Ausführung, Fehlermeldung und Incident-Link. Entfernen Sie Passwörter, Tokens und unnötige personenbezogene Daten. Ein solches Ticket hilft mehr als „Es geht nicht“.

Uptime, SLI, SLO und SLA nicht verwechseln

Nach dem Google-SRE-Modell ist ein SLI eine Messgröße, etwa der Anteil erfolgreicher Anfragen. Ein SLO ist das Ziel für diese Messgröße. Ein SLA ist eine Vereinbarung, die Folgen einer Zielverfehlung regelt.

Die Statusseite ist deshalb kein SLA-Rechner. Für einen möglichen Anspruch zählen der Vertrag, die definierte Messmethode, der Messzeitraum, Ausschlüsse und das vorgeschriebene Meldeverfahren. Mein Rat: Sichern Sie den Incident-Link und Ihre eigenen Nachweise, treffen Sie aber keine Vertragsentscheidung allein anhand der roten Ampel.

Was nach „Resolved“ noch zu tun ist

Prüfen Sie nicht nur, ob die Oberfläche wieder lädt. Kontrollieren Sie die Abläufe, die während der Störung offen waren:

• Wurden Warteschlangen und geplante Jobs nachgeholt?
• Sind Webhooks, E-Mails und Importe vollständig?
• Gibt es doppelte oder nur teilweise verarbeitete Vorgänge?
• Müssen Kunden oder interne Teams eine Abschlussmeldung erhalten?
• Wer übernimmt welchen Folgeschritt bis wann?

Google SRE empfiehlt bei Incident Response eine laufende Aufzeichnung sowie klare Rollen und Kommunikation. Für ein kleines Team reicht oft eine Person für Koordination und eine kurze Liste aus Beobachtung, Entscheidung, Owner und Termin. Bei wichtigen Vorfällen sollte daraus eine knappe Nachbesprechung mit konkreten Maßnahmen entstehen.

Wenn ein SaaS-Dienst geschäftskritisch ist, gehört auch die Wiederanlaufplanung dazu. Der Guide SaaS-Backups: Warum Papierkorb und Versionierung nicht immer reichen erklärt, wann ein getesteter Restore zusätzlich sinnvoll ist. Für Rollen und Ersatzwege hilft außerdem ein kleiner, geübter Notfallplan.

Was die Incident-Historie über einen Anbieter verrät

Ein einzelner Ausfall ist kein fairer Zuverlässigkeitsvergleich. Aussagekräftiger sind Muster über mehrere Ereignisse:

• Werden betroffene Komponenten und Regionen klar benannt?
• Erscheinen Updates mit nachvollziehbaren Zeitstempeln?
• Ändert der Anbieter die Beschreibung, wenn neue Fakten vorliegen?
• Gibt es bei größeren Vorfällen eine Ursachenanalyse und konkrete Folgemaßnahmen?
• Passen öffentliche Meldungen regelmäßig zu Ihren eigenen Beobachtungen?

Auch hier gilt: Eine schöne Historie beweist keine hohe Verfügbarkeit. Statusseiten sind Kommunikationssysteme; manche Updates entstehen manuell, andere automatisiert. Nutzen Sie die Historie als Gesprächsgrundlage bei Beschaffung und Risikoanalyse – zusammen mit SLA, Referenzen, Architektur und Ihren eigenen Anforderungen.

Fazit

Lesen Sie eine SaaS-Statusseite nicht wie eine Wetterampel, sondern wie einen Zwischenbericht. Ordnen Sie Komponente, Region, Zeitpunkt und Incident-Phase Ihrem eigenen Fehlerbild zu. Aktivieren Sie nur sichere Ersatzwege, dokumentieren Sie die Geschäftsauswirkung und prüfen Sie nach „Resolved“ alle liegen gebliebenen Vorgänge.

Die wichtigste Regel lautet: Anbieterstatus und eigene Beobachtung sind zwei getrennte Signale. Erst zusammen ergeben sie eine belastbare Entscheidung.