130.000 Störungsmeldungen, stundenlanger Ausfall von Outlook, Teams und SharePoint: Wie eine fehlerhafte Server-Gesundheitsprüfung Microsoft 365 weltweit lahmlegte.
Am Donnerstag, dem 12. November 2026, erlebte Microsoft eine der schwerwiegendsten Störungen seiner Cloud-Dienste der letzten Jahre. Beginnend um 17:17 Uhr deutscher Zeit konnten Nutzer weltweit plötzlich nicht mehr auf ihre Exchange Online-Postfächer zugreifen – weder über Outlook im Browser, noch über die Desktop-Anwendung oder mobile Geräte. Was zunächst als regionales Problem in Nord- und Südamerika gemeldet wurde, weitete sich innerhalb weniger Minuten zu einem globalen Ausfall aus.
Die Plattform Downdetector verzeichnete gegen 19:00 Uhr deutscher Zeit einen Höchststand von rund 130.000 Störungsmeldungen allein für Outlook. Weitere 47.000 Berichte betrafen Microsoft 365 insgesamt. Unternehmen, Behörden und Bildungseinrichtungen auf allen Kontinenten waren betroffen – mitten im Arbeitstag auf der Nordhalbkugel.
Microsoft veröffentlichte die ersten offiziellen Hinweise unter den Incident-Nummern EX1550543 (Exchange Online) und MO1550821 (Microsoft 365 Suite). Bis zum frühen Freitagmorgen um 2:50 Uhr deutscher Zeit war der Dienst noch nicht vollständig wiederhergestellt, auch wenn Microsoft von „positiven Ergebnissen" bei den Wiederherstellungsmaßnahmen berichtete.
Der Ausfall beschränkte sich nicht auf E-Mail-Dienste. Microsoft bestätigte, dass alle Funktionen, die auf Exchange Online angewiesen sind, beeinträchtigt wurden. Die vollständige Liste der betroffenen Dienste umfasst:
Besonders kritisch: Die Safe-Links-Funktion von Defender war ausgefallen, was bedeutete, dass Nutzer Fehlermeldungen bei Links erhielten, die nichts mit dem Link selbst zu tun hatten – ein potenzielles Sicherheitsrisiko.
Microsoft benötigte mehrere Stunden, um die Ursache des Ausfalls einzugrenzen. Die erste Vermutung – ein unerwarteter Anstieg des Datenverkehrs – erwies sich schnell als falsch. Um 20:18 Uhr deutscher Zeit korrigierte Microsoft seine Einschätzung: „Die erhöhte Last wird nicht durch einen Anstieg des Datenverkehrs verursacht, sondern durch eine Anzahl von Servern, die unerwartet nicht verfügbar wurden."
Die tiefere Untersuchung offenbarte ein systematisches Problem: Die automatisierten Gesundheitsprüfungen der Server schlugen fehl und markierten funktionierende Server fälschlicherweise als ausgefallen. Diese Server wurden daraufhin aus dem Dienst genommen. Die verbliebenen Server mussten die zusätzliche Last übernehmen und wurden dadurch überlastet.
Um 21:57 Uhr deutscher Zeit identifizierte Microsoft die genaue Schwachstelle: „Ein Prozess auf den betroffenen Servern, der für die Herstellung sicherer Verbindungen verantwortlich ist, wird überlastet, was dazu führt, dass die Server aufhören, Anfragen zu verarbeiten."
Als Gegenmaßnahme entwickelte Microsoft eine alternative Methode zur Überprüfung der Server-Gesundheit. Außerdem begann das Unternehmen, „eine kürzlich durchgeführte Netzwerkkonfigurationsänderung rückgängig zu machen, die mit dem Beginn der Auswirkungen korreliert." Dies war das erste Eingeständnis, dass eine interne Änderung der Auslöser gewesen sein könnte.
Weder Microsoft noch unabhängige Sicherheitsforscher fanden Anzeichen für einen Cyberangriff als Ursache des Ausfalls. SecurityWeek und WIRED zitierten übereinstimmend, dass „derzeit kein Hinweis auf einen Cyberangriff vorliegt". Die Störung war eindeutig auf interne Infrastrukturprobleme zurückzuführen.
Interessanterweise blieben die Konkurrenten Amazon Web Services (AWS) und Google Cloud Platform an diesem Tag ohne größere Störungen. Ihre Status-Seiten zeigten keine Vorfälle, und ihre Downdetector-Meldungen erreichten nur etwa 1% der Outlook-Zahlen.
Microsoft versuchte über Nacht mehrere Wiederherstellungsstrategien:
Trotz dieser Bemühungen musste Microsoft um 23:00 Uhr deutscher Zeit einräumen: „Unsere bisherigen Maßnahmen haben nicht die erwartete Entlastung gebracht." Ein besonders frustrierendes Detail: Server, die erfolgreich wiederhergestellt wurden, „können erneut nicht reagieren, sobald sie Datenverkehr empfangen."
Erst um 2:50 Uhr am Freitagmorgen meldete Microsoft erste Erfolge: „Wir sehen positive Ergebnisse bei unseren Bemühungen, die betroffene Infrastruktur neu zu starten." Das Unternehmen kündigte an, die Lösung schrittweise auszuweiten, sobald die Stabilität bestätigt sei.
Für IT-Administratoren war dieser Ausfall besonders frustrierend, weil es praktisch keine lokalen Gegenmaßnahmen gab. Wenn das Problem in Microsofts Rechenzentren liegt, hilft kein Wechsel des Clients, keine Passwort-Zurücksetzung und kein Neuaufbau von Outlook-Profilen.
Empfohlene Maßnahmen während des Ausfalls:
Vorbereitung für den nächsten Ausfall:
ServiceHealth.Read.All)Eine wichtige Klarstellung: Microsoft meldete zu keinem Zeitpunkt Probleme mit eingehenden E-Mails im Sinne von Datenverlust. Die Störung betraf ausschließlich den Zugriff auf Postfächer und die Zustellung konnte verzögert sein.
Wenn ein empfangender E-Mail-Server überlastet ist oder nicht antwortet, reihen sendende Server die Nachrichten in eine Warteschlange ein und versuchen es später erneut. Diese Wiederholungsversuche laufen über festgelegte Zeiträume:
Nur wenn die Zustellung über diesen Zeitraum hinaus scheitert, erhalten Absender eine Fehlermeldung. Bei einem Ausfall von wenigen Stunden – wie am 12. November – sollten alle E-Mails nach Wiederherstellung des Dienstes zugestellt werden.
Der Ausfall vom 12. November war nicht die einzige schwerwiegende Störung von Microsoft 365 im November 2026:
Besonders bemerkenswert: Der Ausfall vom 6. November und der vom 12. November zeigen ähnliche Symptome – Server-Infrastruktur, die in einen „ungesunden Zustand" gerät und Zugriffsanfragen nicht mehr verarbeiten kann. Ob ein Zusammenhang besteht, wird sich erst im abschließenden Störungsbericht zeigen.
Microsofts Service Level Agreement (SLA) für Exchange Online definiert Ausfallzeit eng: „Jeder Zeitraum, in dem Nutzer nicht in der Lage sind, E-Mails mit Outlook Web Access zu senden oder zu empfangen." Der Ausfall vom 12. November fällt eindeutig in diese Definition.
Die Gutschriften richten sich nach der monatlichen Verfügbarkeit:
Der November 2026 hat 43.200 Minuten. Bei 99,9% Verfügbarkeit bleiben 43,2 Minuten Spielraum für Ausfälle, bei 99% sind es 7 Stunden und 12 Minuten. Die Verfügbarkeit wird in Nutzer-Minuten berechnet: Dauer der Störung multipliziert mit der Anzahl betroffener Nutzer.
Für Organisationen, bei denen alle Nutzer länger als 43 Minuten ausgesperrt waren, ist die erste Schwelle bereits überschritten. Bei einem Ausfall von über 7 Stunden – wie er sich am 12. November abzeichnete – würde die 50%-Gutschrift greifen.
Der Microsoft-365-Ausfall vom 12. November 2026 zeigt eindrücklich, wie abhängig moderne Unternehmen von Cloud-Infrastrukturen geworden sind. Wenn ein zentraler Anbieter wie Microsoft ausfällt, bleiben selbst den versiertesten IT-Abteilungen keine Handlungsoptionen – außer abzuwarten.
Die technische Ursache – eine fehlerhafte Server-Gesundheitsprüfung, die funktionierende Server aus dem Dienst nahm – unterstreicht die Komplexität moderner Cloud-Systeme. Selbst Automatisierungen, die eigentlich Stabilität garantieren sollen, können zum Auslöser flächendeckender Ausfälle werden.
Für IT-Verantwortliche bleibt die Lehre: Notfallpläne müssen auch Szenarien einschließen, in denen externe Dienste komplett ausfallen. Redundante Kommunikationskanäle außerhalb der Microsoft-365-Umgebung sind nicht optional, sondern Pflicht. Und E-Mail-Benachrichtigungen für Service-Health-Störungen müssen an Adressen gehen, die nicht beim gleichen Anbieter gehostet werden.
Microsoft hat für die kommenden Geschäftstage vorläufige und abschließende Störungsberichte angekündigt. Erst diese werden zeigen, ob der Ausfall vom 12. November mit den früheren November-Störungen in Verbindung steht – und welche strukturellen Maßnahmen Microsoft ergreift, um ähnliche Vorfälle künftig zu verhindern.
WordPress 7.1.4 schließt 22 Sicherheitslücken – darunter eine kritische Race Condition im Core-Updater, die ohne Authentifizierung Remote Code Execution ermöglicht. Sofortiges Update für alle WordPress-Installationen dringend empfohlen!
weiterlesen: WordPress 7.1.4 Sicherheitsupdate: Kritische Lücke ermöglicht Remote Code ExecutionKritische 0-Day-Lücke in Bricksforge (WordPress): CVE-2026-85097 (CVSS 9.8–10.0) wird seit 7. Oktober aktiv ausgenutzt. Alle Versionen ≤3.1.8.9 betroffen. Sofortiges Update auf 4.0.1 erforderlich.
weiterlesen: Bricksforge WordPress: Kritische Sicherheitslücke CVE-2026-85097 ermöglicht vollständige Server-ÜbernahmeZwei kritische PHP-Schwachstellen (CVE-2026-109618/109619) bedrohen weltweit Millionen Webseiten. BSI warnt mit Stufe Orange. Hunderte deutsche Webseiten offline – inklusive Behörden, Krankenhäuser und Universitäten. Notfall-Updates verfügbar, aber automatisierte Angriffswellen laufen bereits an.
weiterlesen: PHP2Shell: Kritische Sicherheitslücken legen deutsches Internet lahmIhre digitale Vision ist bei uns in besten Händen. Ob Website, Webshop oder individuelle Anwendung – bei CODISH finden Sie Beratung, Umsetzung und Support aus einer professionellen Hand.
Guten Tag, ich bin DASI, der digitale Assistent von CODISH.
Ich kenne die Inhalte dieser Website wie Leistungen, Referenze, Blogbeiträge und beantworte Ihre Fragen dazu mit Angabe der Quellen. Sie müssen also nicht selbst suchen: Fragen Sie einfach, oder beschreiben Sie Ihr Vorhaben, und ich zeige Ihnen die passenden Stellen.
