Drittanbieter-Status sichtbar machen: Externe Abhängigkeiten auf der Statusseite transparent kommunizieren

Mehrere Monitore zeigen Status-Dashboards und Metriken. Bildquelle: Pexels.

Die meisten Statusseiten zeigen den Zustand der eigenen Infrastruktur. Was sie häufig auslassen: die externen Dienste, von denen das eigene System abhängt. Wenn AWS S3 Probleme hat, Stripe eine erhöhte Fehlerquote meldet oder Twilio mit API-Latenzen kämpft, können eigene Dienste beeinträchtigt sein – obwohl die eigene Infrastruktur vollständig gesund ist.

Dashboard mit Status-Anzeigen und Metriken auf mehreren Bildschirmen — Bildquelle: Unsplash / Luke Chesser

Nutzer unterscheiden das nicht. Sie sehen einen nicht funktionierenden Dienst und erwarten Kommunikation. Wer externe Abhängigkeiten transparent macht, gewinnt Vertrauen – auch wenn das Problem nicht im eigenen Einflussbereich liegt.

Warum externe Abhängigkeiten auf Statusseiten oft fehlen

Die Gründe sind nachvollziehbar: Wenn ein Cloud-Provider Probleme hat, kann das eigene Team nichts dagegen tun. Warum also überhaupt kommunizieren? Diese Denkweise verkennt, was Nutzer von Statusseiten wollen: Sie wollen verstehen, warum etwas nicht funktioniert – und ob das Problem bekannt ist. Eine Statusseite, die bei Drittanbieterproblemen still bleibt, erzeugt mehr Verwirrung als eine, die aktiv kommuniziert.

Ein zweiter Grund: technische Aufwände. Das Einbinden externer Status-Feeds erfordert Integrationsarbeit. Für Teams, die ihre Statusseite schon im Grundbetrieb kaum pflegen, bleibt das oft liegen.

Typische Drittanbieter-Abhängigkeiten in modernen IT-Stacks

Welche Drittanbieter für die eigene Statusseite relevant sind, hängt vom Stack ab. Typische Kandidaten:

Cloud-Infrastruktur: AWS, Azure, Google Cloud, Hetzner – Ausfälle in einer Region oder einem Dienst (EC2, RDS, S3) können direkte Auswirkungen haben
Zahlungsabwicklung: Stripe, PayPal, Mollie – Probleme bei Payment-Providern blockieren Transaktionen, auch wenn der eigene Service läuft
CDN und Edge-Netzwerke: Cloudflare, Fastly, Akamai – Latenzen oder Ausfälle betreffen alle dahinterliegenden Dienste
E-Mail- und Notification-Dienste: SendGrid, Mailgun, Twilio – Probleme hier führen zu fehlenden Bestätigungs- und Benachrichtigungs-E-Mails
Authentifizierungs-Provider: Auth0, Okta – wenn der Identity-Provider ausfällt, können Nutzer sich nicht einloggen
KI-APIs: OpenAI, Anthropic, Google AI – bei KI-gestützten Features erzeugen Anbieter-Ausfälle direkt sichtbare Fehler

Wie externe Statusdaten eingebunden werden können

Die meisten großen SaaS-Anbieter betreiben eigene Statusseiten und bieten maschinenlesbare Feeds an. Das gängigste Format sind Atom/RSS-Feeds oder JSON-Endpunkte, die den aktuellen Status und laufende Incidents liefern. Beispiele:

AWS Service Health Dashboard bietet einen RSS-Feed pro Service und Region
Stripe, GitHub und viele andere nutzen Atlassian Statuspage, das JSON-APIs bereitstellt
Cloudflare liefert Incident-Informationen über seinen öffentlichen Status-Feed

Teams mit eigenem Backend können diese Feeds periodisch abfragen, auf Basis der aktuellen Status-Werte eine interne Komponente aktualisieren und so Drittanbieter-Status in die eigene Statusseite einbetten. Der Aufwand ist bei vorhandenen API-Integrationen überschaubar.

Eine Statusseite, die bei einem Drittanbieter-Ausfall aktiv kommuniziert, ist keine Schwäche – sie zeigt, dass das Team den gesamten Stack im Blick hat.

Kommunikationsstrategie bei Drittanbieterproblemen

Die Herausforderung bei externen Ausfällen: Das eigene Team hat keinen Einfluss auf den Zeitplan der Behebung. Trotzdem erwartet man aktive Kommunikation. Ein bewährter Ansatz:

Sofortige Transparenz

Sobald erkannt wird, dass ein Drittanbieter betroffen ist und eigene Dienste darunter leiden, einen Incident auf der Statusseite öffnen. Klarer Hinweis: „Wir verfolgen einen Ausfall bei [Anbieter] und beobachten die Auswirkungen auf [Funktion]. Eigene Systeme sind gesund."

Regelmäßige Updates

Auch wenn es nichts Neues zu berichten gibt, ein kurzes Update setzen: „Der Anbieter hat noch keine Lösung kommuniziert. Wir beobachten die Situation weiter." Das signalisiert, dass das Team aktiv ist und nicht geschlafen hat.

Abschluss mit Kontext

Wenn der Drittanbieter den Incident schließt, den eigenen Incident ebenfalls abschließen – mit einer kurzen Einordnung, welche eigenen Funktionen betroffen waren und ob Datenverlust oder Konsequenzen entstanden sind.

Unterschied: Komponente vs. laufender Incident

Für die Darstellung auf der Statusseite gibt es zwei Ansätze. Eine Komponente für externe Abhängigkeiten zeigt dauerhaft deren Status – ideal, wenn man externe Dienste kontinuierlich überwacht. Ein manuell eröffneter Incident eignet sich für den reaktiven Fall: Man erkennt das Drittanbieterproblem und öffnet einen Incident, der den Kontext erklärt.

Beide Ansätze haben ihre Berechtigung. Teams mit engem Zeitbudget fahren oft gut mit dem reaktiven Ansatz: Drittanbieter-Incidents werden gezielt kommuniziert, ohne dass ein vollständiges Monitoring-Setup nötig ist.

Was Nutzer von dieser Transparenz haben

Aus Nutzerperspektive ist der Mehrwert direkt: Wer sieht, dass ein externes Problem bekannt ist und das Team reagiert, schickt keine Support-Tickets, sucht keine Workarounds, und interpretiert den Ausfall nicht als allgemeine Unzuverlässigkeit des Dienstes. Die wahrgenommene Qualität des Supports und der Kommunikation steigt – auch bei einem Ausfall, den das Team nicht selbst verursacht hat.

Langfristig baut das Vertrauen auf. Nutzer, die sehen, dass eine Statusseite vollständig und ehrlich ist – auch bei Drittanbieterproblemen – trauen ihr auch bei eigenen Incidents mehr.

Praktische Empfehlungen zum Einstieg

Kritische externe Abhängigkeiten inventarisieren: Welche Drittanbieter sind für welche Funktionen essenziell?
Für die wichtigsten Abhängigkeiten prüfen, ob öffentliche Status-Feeds verfügbar sind
Interne Benachrichtigungen einrichten, wenn relevante Drittanbieter einen Incident melden – etwa via RSS oder Webhook
Klare interne Prozessregel: Bei bestätigtem Drittanbieter-Ausfall mit Nutzerauswirkung → Incident auf Statusseite öffnen
Statusseiten-Komponenten für die wichtigsten externen Abhängigkeiten anlegen und sichtbar halten

Drittanbieter auf der Statusseite sichtbar zu machen ist keine große technische Aufgabe. Sie ist vor allem eine organisatorische Entscheidung: Welche Transparenz möchte das Team nach außen zeigen? Wer sich für vollständige Kommunikation entscheidet, legt damit eine Grundlage, auf die Nutzer in Krisenzeiten zurückgreifen können.