Niemand plant einen Ausfall.

Ericsson bestätigte noch am selben Tag, dass ein abgelaufenes Zertifikat in 2 Softwareversionen seiner SGSN-MME-Kernnetzknoten den Ausfall verursacht hatte. Laut SoftBank war die Software seit 9 Monaten im Einsatz. Zur Wiederherstellung musste die ältere Version zurückgespielt werden.

Was ein Check von außen zeigt Das Zertifikat steckte in Herstellersoftware, deshalb hätte ein TLS-Zertifikat-Check es nicht gesehen. Prüfpunkte von außen messen auch den mobilen Datenpfad nicht. Eine Statusseite überbringt die Nachricht an die Kunden, und die Verfügbarkeitsaufzeichnung gibt den Gutschriften eine Grundlage.

• TLS-Zertifikat-Check

Quelle: Pressemitteilung von Ericsson, 2018-12-06 · Pressemitteilung von SoftBank, 2018-12-06 · MoneySavingExpert, 2018-12-07

Microsoft 365 Status schrieb, ein Authentifizierungszertifikat sei abgelaufen und eine Korrektur werde ein neues Zertifikat einspielen. Nutzer konnten sich nicht anmelden.

Was ein Check von außen zeigt Microsoft hat nicht veröffentlicht, ob dieses Zertifikat auf einem öffentlichen Endpunkt lag, deshalb ist offen, ob ein Zertifikat-Check es erkannt hätte. Ein HTTP-Check des Anmeldeablaufs aus mehreren Regionen kann den Fehler nach 2 aufeinanderfolgenden fehlgeschlagenen Checks zeigen, wo auch immer das Zertifikat lag. Eine Statusseite beantwortet die Frage, die Ihre Kunden zuerst stellen: ob es an Ihnen liegt oder an Teams.

• HTTP(S)-Check
• TLS-Zertifikat-Check

{
  "name": "Sign-in page",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://app.example.com/login", "expected_status": 200 }
}

Quelle: TechCrunch, 2020-02-03, zitiert Microsoft 365 Status

Laut Googles Incident-Bericht ließ ein Problem beim Aktualisieren der Zertifikatskonfigurationen das aktive Zertifikat in den Google-Voice-Front-Ends ablaufen.

Was ein Check von außen zeigt Ein TLS-Zertifikat-Check auf dem öffentlichen Endpunkt meldet die Restlaufzeit Tage im Voraus, aus einem System außerhalb der Rotation, die versagt hat. Die Rotation selbst bleibt Aufgabe des Betreibers.

• TLS-Zertifikat-Check

{
  "name": "Voice front-end certificate",
  "type": "ssl_cert",
  "interval_seconds": 900,
  "config": { "host": "voice.example.com", "port": 443, "warn_days": 21 }
}

Quelle: Incident-Bericht von Google Workspace (PDF) · BleepingComputer, 2021-02-28

Das U.S. Government Accountability Office stellte fest, dass ein Zertifikat auf dem Gerät, das den verschlüsselten Netzverkehr inspizierte, etwa 10 Monate vor Beginn des Einbruchs abgelaufen war. Bis zur Erneuerung wurde der Verkehr nicht inspiziert.

Was ein Check von außen zeigt Das Gerät war kein öffentlicher Endpunkt, deshalb hätte ein Zertifikat-Check es nicht gesehen. Der Fall steht nur deshalb hier, weil er zeigt, dass ein abgelaufenes Zertifikat monatelang unbemerkt bleiben kann, wenn niemand Ablaufdaten beobachtet. Die kleinstmögliche Antwort ist ein Inventar aller Ihrer Zertifikate, in dem die öffentlichen von außen geprüft werden.

• TLS-Zertifikat-Check

Quelle: GAO-18-559, 2018-08-30

Während einer Wartung nahm ein Befehl, der die Backbone-Kapazität prüfen sollte, jede Backbone-Verbindung vom Netz, und ein Audit-Werkzeug hielt ihn nicht auf. Metas autoritative DNS-Server ziehen ihre BGP-Ankündigungen zurück, wenn sie die Rechenzentren nicht erreichen, und verschwanden deshalb aus dem Internet, obwohl sie weiterliefen. Die internen Diagnosewerkzeuge fielen mit aus, und Ingenieure mussten die Rechenzentren persönlich betreten.

Was ein Check von außen zeigt Nach 2 aufeinanderfolgenden fehlgeschlagenen Checks melden DNS-Checks aus mehreren Regionen, dass die Domain nirgends mehr auflöst, und Traceroute-Checks zeigen, dass die Routen verschwunden sind. Meta verlor die eigenen Werkzeuge zusammen mit dem eigenen Netz, und ein Blick von außen funktioniert genau in dieser Lage weiter. Eine Statusseite muss auf einer anderen Domain liegen oder zumindest bei einem anderen DNS-Betreiber, sonst verschwindet sie mit.

• DNS-Record-Check
• Traceroute-Check

{
  "name": "Apex A record",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "example.com", "record_type": "A" }
}

Quelle: Meta Engineering, 2021-10-05 · Cloudflare, 2021-10-04

Ein Ingenieur nutzte für einen globalen DNS-Rollout den Notfallprozess für Break-Fix-Änderungen statt des gestuften Verfahrens. Ein 4 Jahre altes Skript lief unter Last in einen Timeout, und die DNS-Server kamen nach dem Neustart nicht zurück. Die Werkzeuge zur Wiederherstellung hingen an genau diesen Servern. Die Statusseite war nur zeitweise erreichbar, was Salesforce auf fehlende automatische Skalierung der Seite zurückführte, nicht auf DNS.

Was ein Check von außen zeigt DNS-Checks aus mehreren Regionen melden den Verlust der Auflösung nach 2 aufeinanderfolgenden fehlgeschlagenen Checks. Wichtiger noch: Eine Statusseite wird genau dann gebraucht, wenn alle gleichzeitig nachsehen, sie muss also außerhalb Ihrer eigenen Plattform laufen und dem Ansturm während eines Incidents standhalten. Das ist eine Eigenschaft einer getrennt betriebenen Statusseite, kein Verdienst des Checks selbst.

• DNS-Record-Check
• HTTP(S)-Check

{
  "name": "App host record",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "app.example.com", "record_type": "A" }
}

Quelle: The Register, 2021-05-12 · The Register, 2021-05-19

Das DNS-Management von DynamoDB arbeitet mit einem Planer und mehreren Enactors. Ein Enactor wandte noch einen alten Plan an, während ein zweiter einen neueren anwandte und den alten Plan anschließend in seinem Bereinigungsschritt löschte. AWS schrieb, mit dem Löschen dieses Plans seien sofort alle IP-Adressen des regionalen Endpunkts entfernt worden. Folgewirkungen auf EC2 und Load Balancer zogen die Wiederherstellung bis in den Nachmittag.

Was ein Check von außen zeigt DNS- und HTTP-Checks Ihrer eigenen Endpunkte aus mehreren Regionen melden den Ausfall nach 2 aufeinanderfolgenden fehlgeschlagenen Checks und zeigen, ob Ihre Region betroffen ist. Die Statusseite gehört außerhalb der Region und der Plattform, auf der Ihre Dienste laufen. Die Verfügbarkeitsaufzeichnung gibt Ihnen eine eigene Zeitreihe für Kundenfragen und für einen Gutschriftsantrag, bei dem Sie die Ausfallzeit nachweisen müssen.

• DNS-Record-Check
• HTTP(S)-Check

{
  "name": "API endpoint record",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "api.example.com", "record_type": "A" }
}

Quelle: AWS Post-Event-Summary, Oktober 2025

Akamai berichtete, ein Software-Konfigurationsupdate um 15:45 UTC habe einen Fehler im DNS-System ausgelöst, und schloss einen Angriff aus.

Was ein Check von außen zeigt Ein DNS-Check aus mehreren Regionen zeigt, dass Ihre eigene Zone nicht mehr auflöst, ohne dass Sie auf die Stellungnahme des Anbieters warten müssen. Die Statusseite darf nicht von demselben DNS abhängen.

• DNS-Record-Check

{
  "name": "Zone name servers",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "example.com", "record_type": "NS" }
}

Quelle: Akamai, 2021-07-22

Bei einem Standardvorgang gab ein berechtigter Ingenieur einen Parameter falsch ein und entfernte mehr Server als beabsichtigt. Darunter war Kapazität der Index- und Placement-Subsysteme von S3, und beide Subsysteme mussten vollständig neu gestartet werden. AWS schrieb, bis 11:37 PST habe es den Status der einzelnen Dienste auf dem Dashboard nicht aktualisieren können, weil die Dashboard-Konsole von S3 abhing. AWS informierte 2 Stunden lang über Twitter und ein Banner und verteilte die Dashboard-Verwaltung später auf mehrere Regionen.

Was ein Check von außen zeigt Der Fall macht eine Regel deutlich: Betreiben Sie die Statusseite nie auf der Infrastruktur, deren Status sie zeigt. Perstat liefert Ihre Statusseite von seiner eigenen Infrastruktur aus, nicht von der überwachten Plattform. HTTP-Checks aus mehreren Regionen hätten die S3-Endpunkte nach 2 aufeinanderfolgenden fehlgeschlagenen Checks als ausgefallen gemeldet. Das wusste AWS selbst, der Gewinn liegt hier also ganz in der unabhängigen Kommunikation.

• HTTP(S)-Check

{
  "name": "Asset storage",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://assets.example.com/health", "expected_status": 200 }
}

Quelle: AWS Post-mortem, März 2017

Eine Berechtigungsänderung auf einem ClickHouse-Cluster ließ eine Abfrage doppelte Spalten-Metadaten liefern. Die Feature-Datei des Bot-Managements wuchs auf die doppelte Größe und überschritt im Proxy eine harte Grenze von 200 Features, und der Prozess brach mit einer Rust-Panic ab. Die unabhängig gehostete Statusseite fiel zur selben Zeit aus einem anderen Grund aus, weshalb das Team zunächst einen koordinierten Angriff vermutete.

Was ein Check von außen zeigt Wenn Sie Cloudflare nutzen, melden HTTP-Checks aus mehreren Regionen mit Quorum nach 2 aufeinanderfolgenden fehlgeschlagenen Checks überall 5xx-Antworten Ihrer Site. Damit ist geklärt, ob das Problem bei Ihnen liegt oder beim Anbieter. Ihre eigene Statusseite auf unabhängiger Infrastruktur bedient Ihre Kunden, während Dashboard und Statusseite des Anbieters nicht erreichbar sind. Beheben konnte hier nur Cloudflare etwas.

• HTTP(S)-Check

{
  "name": "Website behind the CDN",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://www.example.com/", "expected_status": 200 }
}

Quelle: Cloudflare-Blog, 2025-11-18

Am 29. Mai erreichte eine Funktion für zusätzliche Quota-Policy-Prüfungen Service Control, ohne Feature-Flag und ohne Fehlerbehandlung auf dem neuen Pfad. Am 12. Juni erzeugte eine Policy-Änderung leere Felder, und die Binaries stürzten weltweit mit einem Null-Pointer-Fehler ab. Google schrieb, der erste Incident-Bericht sei etwa eine Stunde nach Beginn der Abstürze erschienen, weil die Infrastruktur von Cloud Service Health selbst ausgefallen war. Außerdem schrieb Google, dass bei manchen Kunden auch die auf Google Cloud betriebene Monitoring-Infrastruktur ausfiel, sodass ihnen jedes Signal des Incidents fehlte.

Was ein Check von außen zeigt Dieser letzte Satz begründet externes Monitoring in den Worten des Betreibers: Monitoring auf derselben Plattform fällt mit ihr aus. Perstat prüft von außen, aus bis zu 6 Regionen mit Quorum, und sein Prüfnetz läuft nicht auf der Plattform, die es beobachtet. Eine Statusseite auf getrennter Infrastruktur hätte Ihre Kunden in dieser Stunde informiert.

• HTTP(S)-Check
• DNS-Record-Check

{
  "name": "Public API",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://api.example.com/health", "expected_status": 200 }
}

Quelle: Incident-Bericht von Google Cloud, 2025-06-12 · The Register, 2025-06-16

Ein Skript, das Instanzen einer eingestellten App löschen sollte, erhielt Site-IDs statt App-IDs und löschte ab 07:38 UTC über 23 Minuten ganze Kunden-Sites. Das erste Kundenticket kam um 07:46 UTC, nach 8 Minuten, und der Major-Incident-Prozess begann um 08:17 UTC. Das erste Update der Statusseite kam um 09:03 UTC, nach 85 Minuten, die erste breite öffentliche Stellungnahme in sozialen Medien am 7. April, nach 41 Stunden. Die Wiederherstellung dauerte bis zu 14 Tage und war nur teilweise automatisiert.

Was ein Check von außen zeigt Ein HTTP-Check Ihrer eigenen Tenant-URL aus mehreren Regionen meldet den Ausfall nach 2 aufeinanderfolgenden fehlgeschlagenen Checks, ohne auf ein Support-Ticket zu warten. Manche Kunden verloren Statuspage und Opsgenie zusammen mit ihren Sites, deshalb dürfen Statusseite und Alarmierung nicht bei dem Anbieter liegen, dessen Ausfall sie zeigen sollen. Die 14 Tage hätte kein Monitoring verkürzt.

• HTTP(S)-Check

{
  "name": "Tenant site",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://yourteam.example.com/", "expected_status": 200 }
}

Quelle: Atlassian Post-Incident-Review, 2022-04-29

Der CEO schrieb, das Unternehmen verlängere jedes Jahr Tausende Domains mit Präzision, und doch sei der Auto-Renew-Prozess für die Hauptdomain fehlgeschlagen. Als Ursache nannte die Stellungnahme menschliches Versagen und Prozessfehler. Kunden beschwerten sich öffentlich auf Twitter.

Was ein Check von außen zeigt Ein Domain-Check meldet das Ablaufdatum Tage im Voraus, aus einem System, das nicht von der fehlgeschlagenen automatischen Verlängerung abhängt. Ein DNS-Check aus mehreren Regionen hätte den Verlust der Auflösung nach 2 aufeinanderfolgenden fehlgeschlagenen Checks gemeldet. Eine Statusseite auf einer anderen Domain hätte die Nachricht überbracht, während marketo.com nicht auflöste, aber verlängern kann die Domain kein Check.

• Domain-Check
• DNS-Record-Check

{
  "name": "Company domain",
  "type": "domain",
  "interval_seconds": 300,
  "config": { "domain": "example.com", "warn_days": 30 }
}

Quelle: Marketo Knowledge Base (Adobe), P1 July 25, 2017 · The Drum, 2017-07-26

Ob 2003 Nutzer betroffen waren, ist nicht dokumentiert, deshalb zählt dieser Fall als Kontrollverlust, nicht als Ausfall.

Was ein Check von außen zeigt Ein Domain-Check mit Ablaufwarnung auf jeder Domain, die Sie besitzen, auch auf denen, an die niemand denkt.

• Domain-Check

{
  "name": "Secondary domain",
  "type": "domain",
  "interval_seconds": 300,
  "config": { "domain": "example.co.uk", "warn_days": 30 }
}

Quelle: Slashdot, 1999-12-25 · The Register, 2003-11-06

Beim Reparieren der Replikation entfernte ein Ingenieur das Datenverzeichnis auf dem Primary statt auf dem Secondary. Die pg_dump-Backups existierten nicht, weil das Skript pg_dump 9.2 gegen PostgreSQL 9.6 laufen ließ und fehlschlug. GitLab schrieb, Benachrichtigungen über fehlgeschlagene Cron-Jobs seien per E-Mail versandt worden, doch für diese E-Mails sei DMARC nicht aktiviert gewesen, und der Empfänger habe sie abgewiesen. Disk-Snapshots waren für die Datenbankserver nicht aktiviert, und übrig blieb nur ein manueller LVM-Snapshot, 6 Stunden alt.

Was ein Heartbeat zeigt Ein Heartbeat arbeitet als Totmannschalter: Der Backup-Job meldet sich nach Erfolg, und Perstat alarmiert, wenn die Meldung ausbleibt, ob eine Fehler-E-Mail ankommt oder nicht. Der Fall zeigt auch, dass Alarmierung nicht an einem Kanal hängen darf, der selbst ausfallen kann, deshalb sollte die Eskalation über mehrere Wege laufen und eine Quittung verlangen. Ob sich das Backup wiederherstellen lässt, prüft ein Heartbeat nicht, das bleibt Aufgabe eines Restore-Tests.

• Heartbeat-Check

{
  "name": "Nightly database backup",
  "type": "heartbeat",
  "config": { "period_seconds": 86400, "grace_seconds": 1800 }
}

Quelle: GitLab Post-mortem, 2017-02-10 · The Register, 2017-02-01, zu den 5 Backup-Verfahren

Ein Brand in der Nacht zum 10. März 2021 zerstörte das Rechenzentrum SBG2 in Straßburg und einen Teil von SBG1, und SBG1 bis SBG4 gingen offline. In 2 Urteilen aus dem Jahr 2023 stellte das Gericht fest, dass die vertraglich zugesagte physische Trennung der Backups nicht gegeben war. OVHcloud legte gegen das erste Urteil Berufung ein und wollte laut Blocks and Files auch das zweite anfechten.

Was ein Heartbeat zeigt Ein Heartbeat belegt, dass ein Backup-Job gelaufen ist, aber nicht, wo die Kopie liegt oder ob sie sich an einem anderen Standort wiederherstellen lässt. HTTP-Checks aus mehreren Regionen hätten den Ausfall nach 2 aufeinanderfolgenden fehlgeschlagenen Checks gemeldet. Eine Statusseite bei einem anderen Anbieter hätte die Kunden erreicht.

• Heartbeat-Check
• HTTP(S)-Check

{
  "name": "Off-site backup copy",
  "type": "heartbeat",
  "config": { "period_seconds": 86400, "grace_seconds": 1800 }
}

Quelle: Netcraft, 2021-03-09 · Blocks and Files, 2023-03-23

Die zentrale IT aktualisierte die Software für die nächtliche Kontenverarbeitung, sah Probleme und deinstallierte das Update, ohne die Folgen zu testen. Die Versionen waren inkompatibel, die Stapelverarbeitung blieb stehen, und die Buchungen stauten sich über Wochen. Die FCA nannte das Versäumnis, angemessene Systeme und Kontrollen zur Erkennung und Steuerung von IT-Risiken einzurichten.

Was ein Heartbeat zeigt Ein Heartbeat je Batch-Lauf meldet den fehlenden Tagesabschluss noch in derselben Nacht. HTTP-Checks auf die Kundenportale liefern den Blick von außen, und die Verfügbarkeitsaufzeichnung gibt der Aufsicht eine Zeitreihe statt Schätzungen. Den fehlerhaften Rollback oder die Wochen der Aufräumarbeit hätte kein Monitoring geändert. Die Höhe des Bußgelds zeigt, was eine Aufsicht unter fehlenden Kontrollen versteht.

• Heartbeat-Check
• HTTP(S)-Check

{
  "name": "Nightly batch close",
  "type": "heartbeat",
  "config": { "period_seconds": 86400, "grace_seconds": 3600 }
}

Quelle: Financial Conduct Authority, 2014-11-20

Neuer Code wurde auf 7 von 8 Servern ausgerollt. Der achte behielt alten Code, der eine seit 2003 ungenutzte Funktion reaktivierte. Vor Börsenöffnung schickte ein internes System 97 E-Mails mit Verweis auf den Router-Fehler an eine Gruppe von Beschäftigten, und laut SEC reagierte niemand darauf.

Was ein Check von außen zeigt Das war kein Verfügbarkeitsausfall, aber der Fall spricht für Alarmierung, die eine Quittung verlangt. Den Softwarefehler hätte Perstat nicht erkannt, deshalb steht der Fall hier allein für die Alarmierungslogik.

Quelle: U.S. Securities and Exchange Commission, 2013-10-16

Die BaFin nannte Ausfälle im Online- und Mobile-Banking und die mangelnde telefonische Erreichbarkeit des Kundenservice. Außerdem nannte sie lange Bearbeitungszeiten bei Pfändungs- und Nachlassangelegenheiten, Kontoauflösungen und der Rückzahlung von Spareinlagen sowie erhebliche Beeinträchtigungen bei Pfändungsschutzkonten. Der Sonderbeauftragte sollte die zügige und vollständige Beseitigung der Einschränkungen überwachen und regelmäßig berichten.

Was ein Check von außen zeigt HTTP-Checks aus mehreren Regionen zeichnen den Teil auf, der von außen messbar ist: die Ausfälle im Online- und Mobile-Banking. Eine Verfügbarkeitsaufzeichnung, die ihre Grenzen offenlegt, gibt Aufsicht und Kunden Zahlen statt Zusicherungen. Der größere Teil, Bearbeitungsrückstände und Telefonservice, ist kein Thema für Monitoring. Wer Verfügbarkeit behauptet, sollte sie belegen können, bevor die Aufsicht fragt.

• HTTP(S)-Check

{
  "name": "Online banking login",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://banking.example.com/login", "expected_status": 200 }
}

Quelle: BaFin, 2023-09-04 · BaFin, 2023-10-02 · heise online, 2023-10-02 · onvista (Reuters), 2023-07-03, zu den Migrationszahlen

Das Bayerische Landesamt für Steuern sprach von sehr hoher Nachfrage und schloss einen Angriff aus. Die Schnittstelle für Steuersoftware funktionierte weiter.

Was ein Check von außen zeigt HTTP-Checks mit Antwortzeiten aus mehreren Regionen zeigen die Verschlechterung vor dem Ausfall und hinterlassen die Zeitreihe. Eine Statusseite mit Hinweis senkt die Zahl der Neuladeversuche. Das war ein Kapazitätsproblem, von dem der Betreiber wusste, kein Erkennungsproblem. Deshalb steht der Fall hier als Beispiel aus dem öffentlichen Sektor für Reichweite und Kommunikationsbedarf.

• HTTP(S)-Check

{
  "name": "Tax portal",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://portal.example.com/", "expected_status": 200 }
}

Quelle: heise online, 2022-07-11 · Haufe, 2022-07-13

Laut dem Lagebericht des BSI von 2017 brachte ein weltweiter Angriff einer Mirai-Variante auf Port 7547 die Telekom-Router zum Absturz. Die Router wurden nicht infiziert, reagierten aber fehlerhaft auf die Anfragen.

Was ein Check von außen zeigt Das waren Endkundengeräte, der Fall hat also keinen Bezug zum Produkt. Er steht hier nur als deutsches Beispiel für die Reichweite eines Infrastrukturausfalls.

Quelle: BSI, Die Lage der IT-Sicherheit in Deutschland 2017, Seite 15 · The Register, 2016-11-28