Cloud-Ausfälle 2025: Fremde Abhängigkeiten überwachen

Was 2025 gezeigt hat: drei Ausfälle, die halbe Netze lahmlegten

Die drei prominentesten Vorfälle des Jahres hatten eine gemeinsame Signatur: Ein interner, für sich genommen banaler Auslöser bei einem einzigen Anbieter pflanzte sich über abhängige Dienste fort und traf tausende Websites, die selbst nichts falsch gemacht hatten. Beim Ausfall in US-EAST-1 am 20. Oktober 2025 löste eine latente Wettlaufsituation in der DNS-Verwaltung eines Datenbankdienstes eine Kaskade aus, die Instanzverwaltung und Netzwerkfunktionen mitriss und rund 15 Stunden andauerte (AWS). Schätzungen zu den versicherten Schäden allein dieses Vorfalls reichten bis zu 581 Mio. US-Dollar (CyberCube). Nur neun Tage später sorgte eine fehlerhafte Konfigurationsänderung an einem großen Content-Delivery-Dienst für einen rund 8-stündigen Ausfall (Microsoft). Und am 18. November verdoppelte eine Datenbank-Berechtigungsänderung eine interne Konfigurationsdatei, bis das Traffic-Routing eines zentralen Edge-Netzes ein internes Limit riss und für gut 3,5 Stunden ausfiel - die vollständige Wiederherstellung zog sich noch bis in den frühen Abend (Cloudflare).

Auffällig ist, dass keiner dieser Ausfälle durch einen Angriff verursacht wurde - es waren interne Fehler, ausgelöst durch Routineänderungen (AWS, Microsoft, Cloudflare). Für Betreiber bedeutet das eine unbequeme Wahrheit: Selbst technisch hochwertig aufgestellte Anbieter fallen gelegentlich aus, und die eigene Erreichbarkeit hängt an Gliedern einer Kette, die man weder sieht noch kontrolliert. Ein einzelner Anbieter, den viele gleichzeitig nutzen, wird so zum geteilten Risiko: Fällt er aus, fallen alle mit, die auf ihn setzen.

Warum fremde Abhängigkeiten zum Single Point of Failure werden

Eine moderne Website ist kein in sich geschlossenes System, sondern ein Geflecht aus Diensten. Die mediane Desktop-Seite bindet 83 Drittanbieter-Requests ein, auf dem Smartphone sind es 79 (Web Almanac 2025). Jeder dieser Aufrufe ist eine Abhängigkeit: ein Nameserver, ein CDN, eine Schrift-Bibliothek, ein Zahlungsdienstleister, ein Login-Provider, eine Analyse- oder Kartenkomponente. Fällt ein einziges kritisches Glied aus, kann die ganze Seite unbrauchbar werden, obwohl der eigene Webserver tadellos antwortet.

Besonders schwer wiegen die tragenden Glieder ganz vorne in der Kette. DNS und CDN entscheiden, ob ein Besucher Ihre Seite überhaupt findet und ausgeliefert bekommt. Sie liegen vor Ihrem Webserver, also außerhalb Ihrer eigenen Health-Checks. Genau hier lagen 2025 die schwersten Ausfälle: Ein Namensauflösungsfehler in einer Cloud-Region riss ganze Dienstlandschaften mit (AWS), ein Edge-Netz verweigerte tausenden Seiten die Auslieferung (Cloudflare). Auch Zahlungs- und Login-APIs sind kritisch: Steht die Zahlung, bricht der Umsatz weg, selbst wenn der Katalog noch lädt. Das Monitoring von DNS und Domain und der eingebundenen Programmierschnittstellen gehört deshalb genauso zur Überwachung wie die eigentliche Startseite.

Was ein Ausfall wirklich kostet

Ausfallzeit ist kein reines Technikthema, sondern eine Umsatzfrage. Laut der ITIC-Erhebung 2024 kostet eine einzige Stunde Ausfall bei über 90 % der mittleren und großen Unternehmen mehr als 300.000 US-Dollar (ITIC 2024). Bei größeren Unternehmen geben 41 % an, dass eine Ausfallstunde zwischen 1 und über 5 Mio. US-Dollar verschlingt (ITIC 2024) - Kosten für Rechtsstreitigkeiten oder Vertragsstrafen dabei noch nicht eingerechnet. Für einen kleinen Onlineshop fällt die absolute Summe kleiner aus, doch relativ zum Umsatz trifft ein mehrstündiger Ausfall an einem Aktionstag genauso hart.

Zu den direkten Einnahmeverlusten kommen indirekte Kosten, die länger nachwirken. Support-Kanäle laufen voll, weil Kunden nicht wissen, ob das Problem bei ihnen oder bei Ihnen liegt. Das Vertrauen leidet, wenn Besucher wiederholt auf Fehlerseiten stoßen und keine Erklärung finden. Und Suchmaschinen bewerten die Nutzererfahrung mit: Wiederholte Nichterreichbarkeit und Timeouts können sich mittelbar auf Sichtbarkeit und Ranking auswirken. Ein mehrstündiger Ausfall ist damit nicht nur ein verlorener Nachmittag, sondern ein Ereignis mit Nachlauf.

Die blinde Stelle: Wenn der eigene Server läuft, aber Kunden nichts sehen

Die gefährlichste Lücke entsteht dort, wo die Überwachung aus derselben Infrastruktur kommt, die sie prüfen soll. Ein interner Health-Check meldet fröhlich grün, weil der Webserver antwortet - während DNS, CDN oder eine zentrale API davor bereits ausgefallen sind und kein Besucher mehr durchkommt. Das Dashboard zeigt Normalbetrieb, das Telefon klingelt trotzdem. Genau dieses Muster prägte die großen Vorfälle 2025: Der eigene Code lief, doch die Kette davor war unterbrochen. Nur eine Messung von außen, aus einer unabhängigen Region, deckt diese blinde Stelle auf.

Fremde Endpunkte gezielt überwachen

Der erste praktische Schritt ist eine Liste aller externen Dienste, die für den Geschäftsbetrieb zählen. Für jeden davon lässt sich ein eigener Check definieren, der aus mehreren Regionen in kurzen Abständen ausgeführt wird. Fällt der Dienst aus, sehen Sie es an der Wurzel und nicht erst am Symptom auf der Startseite. Eine einfache, maschinenlesbare Grundlage sieht so aus:

[
  { "name": "DNS / Nameserver", "type": "dns",  "target": "example.com",                  "interval_s": 60 },
  { "name": "CDN-Asset",        "type": "http", "url": "https://cdn.example.com/health",   "expect": 200 },
  { "name": "Zahlungs-API",     "type": "http", "url": "https://api.pay.example/status",   "expect": 200 },
  { "name": "Login / Auth",     "type": "http", "url": "https://auth.example.com/healthz", "expect": 200 }
]

Neben den erreichbaren HTTP-Endpunkten lohnt der Blick auf Dienste, die selbst aktiv melden sollten - etwa nächtliche Importe, Zahlungs-Abgleiche oder Backups. Bleibt ein solches Signal aus, ist das genauso alarmwürdig wie ein direkter Fehler. Solche stillen Aussetzer fängt eine Überwachung über Heartbeats, die bei ausbleibendem Puls anschlägt. Worauf es beim Zuschnitt der Checks ankommt:

• DNS und Domain: Namensauflösung, Nameserver-Antworten und Ablauf-Fristen überwachen, damit ein Wechsel oder Ausfall beim Registrar oder DNS-Anbieter nicht unbemerkt bleibt.
• CDN und Edge: ein kleines Health-Asset über das Auslieferungsnetz abrufen, um Edge-Ausfälle vor der Startseite zu erkennen.
• Zahlung und Login: die Status-Endpunkte der kritischen APIs prüfen, denn hier hängt der Umsatz direkt am Fremddienst.
• Zertifikate: kurze Laufzeiten und automatische Erneuerung im Blick behalten - mehr dazu im Beitrag zu 6-Tage-Zertifikaten im SSL-Monitoring.
• Mehrere Regionen: jeden Check aus verschiedenen Standorten fahren, damit ein regionaler Netzfehler nicht als globaler Ausfall fehlgedeutet wird.

Eine Statusseite, die auch dann sendet, wenn Ihr Server steht

Wenn eine Seite ausfällt, wollen Kunden vor allem eines wissen: Liegt es an mir oder an euch, und wann ist es wieder gut? Eine öffentliche Statusseite beantwortet das, bevor die erste Support-Anfrage eintrifft. Entscheidend ist, dass sie unabhängig von der überwachten Infrastruktur betrieben wird. Läge sie auf demselben Server oder hinter demselben CDN, ginge sie im selben Moment mit unter - und wäre genau dann nutzlos, wenn man sie am dringendsten braucht.

Eine gute Statusseite zeigt den Live-Zustand der Komponenten, dokumentiert vergangene Vorfälle mit Zeitstempeln und lässt Kunden Benachrichtigungen abonnieren - per E-Mail oder Feed. So verschiebt sich die Kommunikation vom reaktiven Abarbeiten einzelner Anfragen zum aktiven Informieren aller Betroffenen gleichzeitig. Das entlastet den Support in genau der Stunde, in der er am stärksten unter Druck steht.

Redundanz und Runbooks: Resilienz ist mehr als Monitoring

Monitoring ist die Erkennungsebene - es verkürzt die Zeit bis zur Reaktion, verhindert den Ausfall aber nicht. Resilienz entsteht erst im Zusammenspiel mit vorbereiteten Maßnahmen. Dazu zählen ein zweiter Nameserver bei einem unabhängigen Anbieter, kurze DNS-Vorhaltezeiten für schnelles Umschalten, ein Ausweichpfad für die Auslieferung statischer Inhalte und ein klar dokumentiertes Runbook, das im Ernstfall Schritt für Schritt vorgibt, wer was tut. Wichtig ist, diese Notfallpläne regelmäßig zu proben, statt sie nur abzulegen - ein ungetesteter Plan versagt typischerweise genau dann, wenn es zählt.

Ein Resilienz-Fahrplan in fünf Schritten

1. Abhängigkeiten inventarisieren: Listen Sie alle fremden Dienste auf, von denen Ihre Seite abhängt - DNS, CDN, Zahlung, Login, Schriften, Analyse. Ohne diese Karte lässt sich nichts absichern.
2. Von außen überwachen: Prüfen Sie Startseite und kritische Endpunkte aus mehreren Regionen, statt sich auf interne Health-Checks zu verlassen, die im Ausfall grün bleiben.
3. Statusseite aufsetzen: Betreiben Sie eine Statusseite getrennt von der eigenen Infrastruktur, mit Abo-Funktion und Vorfall-Chronik, damit Kunden auch bei Totalausfall informiert bleiben.
4. Alarmwege festlegen: Definieren Sie, wer über welchen Kanal benachrichtigt wird und was passiert, wenn niemand reagiert - inklusive Eskalationsstufe.
5. Notfallpläne proben: Halten Sie ein Runbook aktuell und spielen Sie den Ernstfall durch, damit die Reaktion im echten Vorfall sitzt statt improvisiert zu werden.

Externes Monitoring und Statusseite mit XICTRAQ einrichten

Die Ausfälle 2025 haben eine Lektion hinterlassen: Verfügbarkeit ist kein Zustand, den man einmal herstellt, sondern eine Kette, die man laufend beobachten muss. Weil die kritischen Glieder oft außerhalb der eigenen Kontrolle liegen, gehört das Uptime-Monitoring fremder Endpunkte genauso in den Werkzeugkasten wie die Überwachung der eigenen Startseite. Erkennen, kommunizieren, reagieren - in dieser Reihenfolge begrenzt sich der Schaden.

XICTRAQ prüft Ihre Website und die eingebundenen Drittanbieter-Endpunkte aus mehreren Regionen, alarmiert über mehrere Kanäle und betreibt eine Statusseite, die unabhängig von Ihrer Infrastruktur sendet. So sehen Sie einen Ausfall an der Wurzel, informieren Kunden aktiv und halten den Vorfall für die spätere Analyse fest - statt ihn erst an sinkenden Bestellzahlen abzulesen. Wie sich Domain- und DNS-Daten dabei zuverlässig überwachen lassen, zeigt der Beitrag zu RDAP im Domain-Monitoring.

Starten Sie mit dem kostenlosen Test und prüfen Sie, welche fremden Endpunkte Ihre Seite heute wirklich tragen. Oder vereinbaren Sie eine persönliche Demo, um Monitoring, Alerting und Statusseite im Zusammenspiel zu sehen.