Microsoft hat für drei Störungen der Jahre 2026 einen Post Incident Review veröffentlicht: West US am 23. Juli, Foundry in Sweden Central am 29. September und Netzwerk-Gateways in 33 genannten Regionen am 30. September und 1. Oktober, darunter Austria East, Germany North, Germany West Central und Switzerland North. Der Artikel fasst Dauer, Dienste und Ursachen zusammen, nennt Microsofts Verbesserungstermine und zeigt, welche Alarme, Wiederholungsstrategien und Architekturentscheidungen Administratoren und Entwickler jetzt prüfen sollten.
Fast sechs Stunden lang liefen Netzwerk-Gateways in 33 Azure-Regionen nur eingeschränkt. Das war in der Nacht zum 1. Oktober. Microsoft hat zu drei Störungen dieses Jahres Berichte veröffentlicht. Die endgültigen Fassungen zu den beiden Herbststörungen sind nach dem 8. Oktober 2026 erschienen, vorher standen dort nur vorläufige Meldungen. Hier steht, was geschah und warum Kunden wenig tun konnten. Dazu kommt, was du trotzdem vorbereiten kannst.
Das Wichtigste in Kürze
- Am 30. September fielen Netzwerk-Gateways in 33 genannten Regionen aus. Der Ausfall dauerte von 20:30 UTC bis 02:15 UTC, also 5 Stunden und 45 Minuten. Er traf auch Regionen in der Schweiz und ihren Nachbarländern.
- Ursache war eine überlastete Steuerebene. Nach dem Ablauf einer Bereitstellungssperre liefen sehr viele Gateway-Updates gleichzeitig an.
- Am 29. September war Foundry in Sweden Central knapp sechs Stunden gestört. Betroffen waren Azure OpenAI, der Agent Service und die Modelle.
- Am 23. Juli traf es West US rund fünf Stunden lang. Ein Fehler in einer Sicherheitsprüfung erweiterte eine Wartung auf alle ausgehenden optischen Geräte eines Rechenzentrums.
- Microsoft will die Schwachstellen bis Juni 2027 beheben. Einzelne Massnahmen sind schon abgeschlossen.
Die drei Störungen im Vergleich
Die Berichte stammen aus der Azure-Störungshistorie. Alle Zeiten sind UTC. Die Schweiz ist der UTC bis zum 25. Oktober zwei Stunden voraus.
| Datum und Dauer | Dienst und Region | Ursache |
|---|---|---|
| 23. Juli, 4 h 57 min | Viele Dienste in West US, etwa App Service, Cosmos DB, AKS | Fehler in der Wirkungsradius-Analyse erweiterte eine Reparatur auf alle optischen Geräte |
| 29. September, 5 h 55 min | Azure OpenAI, Foundry Agent Service, Foundry Models in Sweden Central | Cache-Leerung bei einem Deployment, dazu zwei Fehler in der Cache-Logik |
| 30. September bis 1. Oktober, 5 h 45 min | Gateways, ExpressRoute, Firewall und mehr in 33 genannten Regionen | Viele Updates gleichzeitig plus eine frühere Änderung an der Steuerebene |
Azure-Gateways in 33 Regionen
Betroffen waren ExpressRoute, VPN, Application Gateway, Firewall, Bastion, Virtual WAN und Azure VMware Solution. Verwaltungsvorgänge scheiterten zeitweise. Ein Teil der aktualisierten ExpressRoute-Gateways verlor kurz die Verbindung. In der Liste stehen unter anderem West Europe, Austria East, Germany West Central und Switzerland North. Eine Gesamtzahl nennt der Bericht nicht, die 33 habe ich abgezählt. Der Text sagt „multiple regions including“. Die Liste muss also nicht vollständig sein.
Dabei löste eine ablaufende Bereitstellungssperre das Ganze aus. Sie hatte Betriebssystem-Updates für eine Gruppe von Gateways angehalten. Nach ihrem Ende starteten viele Updates kurz hintereinander, und die Geräte holten sich gleichzeitig ihre Konfiguration. Eine frühere Änderung hatte diese Anfragen zudem verlangsamt. Beides zusammen überlastete die gemeinsame Steuerebene einer Region. Die vorhandene Drosselung schützte die kritischen Abläufe laut Bericht nicht ausreichend.
Damit war nichts zu machen: Laut Microsoft hätten Kunden die Auswirkung weder vermeiden noch abschwächen können. Die Gegenmassnahmen laufen gestaffelt. Angehaltene Updates sollen im Oktober 2026 in Stufen weiterlaufen. Strengere Gesundheitsprüfungen für ExpressRoute folgen im März 2027, bessere Drosselung und Lastabwurf im Juni 2027.
Foundry in Sweden Central am 29. September
Zwischen 10:03 und 15:58 UTC kamen Anfragen nur unregelmässig durch oder endeten in HTTP-500- und 503-Fehlern. Auslöser war ein planmässiges Deployment eines internen Dienstes, das dessen Caches leerte. Es fiel in die Spitzenzeit der Region, also gab es sehr viele Cache-Fehlgriffe. Zwei weitere Fehler in der Cache-Logik verstärkten das. Am Ende sah das Backend etwa zwanzigmal so viel Verkehr wie üblich.
Zudem zog sich die Störung hin, weil die Gesundheitsprüfung der Instanzen an der Datenbankverbindung hing. Wer keine neue Verbindung aufbauen konnte, galt als defekt und wurde neu gestartet. Wiederholte Anfragen der Clients erhöhten die Last zusätzlich. Welche Modelle in Foundry laufen und was sie kosten, steht im Artikel über GPT-6 in Microsoft Foundry.
West US am 23. Juli
Dabei startete eine automatische Reparatur an einem optischen Gerät. Ein Fehler in der Wirkungsradius-Analyse dehnte sie auf alle ausgehenden Geräte eines Rechenzentrums aus. Die Prüfung sah jedes Gerät einzeln an. Dass alle zusammen die Ersatzpfade kappen, bemerkte sie nicht. Verkehr in die Region und aus ihr litt, Verkehr innerhalb nicht. Die Leitungen sahen gesund aus. Erst um 17:19 UTC erkannten die Ingenieure den Zusammenhang.
Monitoring mit Service Health
Daher empfehlen alle drei Berichte Service-Health-Alarme. Sie melden Störungen, geplante Wartung, Gesundheitshinweise und Sicherheitshinweise per E-Mail, SMS, Push oder Webhook. Microsoft zeigt in der Anleitung für Service-Health-Alarme mit Bicep eine Vorlage, die Aktionsgruppe und Alarm anlegt. Bereitgestellt und geprüft wird sie so:
az deployment group create --name CreateServiceHealthAlert --resource-group my-resource-group --template-file CreateServiceHealthAlert.bicep --parameters emailAddress='[email protected]'
az monitor activity-log alert show --resource-group my-resource-group --name ServiceHealthActivityLogAlert
Wer Service-Health-Daten lieber in eigene Werkzeuge einspeist, findet im Artikel über den MCP-Server für Microsoft 365 die passenden Graph-Schnittstellen.
Was du jetzt tun solltest
- Lege einen Service-Health-Alarm für jedes produktive Abonnement an und teste, dass die Meldung die richtigen Personen erreicht.
- Baue Wiederholungen mit exponentiellem Backoff und Jitter ein. Die Hinweise zu Übergangsfehlern warnen zugleich vor endlosen Wiederholungen, die eine Überlast verlängern.
- Plane für kritische Dienste mehrere Regionen, wie Microsoft im West-US-Bericht rät. Die Grundlagen stehen im Leitfaden zu Regionen und Verfügbarkeitszonen.
- Lies für Foundry die Anleitung zur Notfallwiederherstellung des Agent Service. Sie hält fest, dass der Dienst keine eigene Wiederherstellung bietet und dass ein Failover in eine andere Region die Projekte neu anlegt.
- Prüfe deine Architektur mit dem Well-Architected Framework für Zuverlässigkeit.
Fazit
Zwei der drei Störungen entstanden durch Änderungen, die gleichzeitig viel zu viel auslösten: ein Deployment, das Caches leerte, und viele Updates nach einer Sperre. Kunden konnten den Gateway-Ausfall nicht verhindern, wohl aber seine Folgen kleiner halten, mit Alarmen, sauberen Wiederholungen und einem zweiten Standort. Lege diese Grundlagen an, bevor die nächste Störung kommt.
Quellen: Azure-Störungshistorie mit den Berichten 7Q30-010, 7QL5-Z50 und ZJV6-SGG, Service-Health-Alarme mit Bicep, Übergangsfehler behandeln, Regionen und Verfügbarkeitszonen, Foundry Agent Service: Notfallwiederherstellung, Well-Architected Framework: Zuverlässigkeit. Foto: Felix-Mittermeier / Pixabay. Stand: 12. Oktober 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.