Störungsverlauf von Knowbe4

1. 20. Oktober 2026 um 11:37 UTCidentified

   Wir haben festgestellt, dass die Ursache der Domainregistrierung nicht in der Lage ist, Ratschläge zu geben, und arbeiten an der Implementierung eines Fixes. Wir werden weiterhin auf unserer Statusseite mit neuen Informationen oder Updates posten.

2. 21. Oktober 2026 um 15:33 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 23. Oktober 2026 um 14:55 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 15:03 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das sich auf die Konsolenanmeldung auswirkt. Wir werden hier weitere Updates zur Verfügung stellen, wenn verfügbar.

2. 13. Oktober 2026 um 15:07 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 13. Oktober 2026 um 16:15 UTCresolved

   Dieser Vorfall wurde behoben.

4. 14. Oktober 2026 um 14:29 UTCpostmortem

   ## **Zusammenfassung** Am 13. Oktober 2026, von ca. 14:19 bis 15:05 \(UTC\), konnten sich Kunden in allen Regionen nicht an der KnowBe4 Security Awareness Training \(SAT\)-Konsole, der KnowBe4 Learner Experience und der PhishER-Konsole über KnowBe4 SAT anmelden. SAML- und Passwort-Anmeldungen haben Fehler zurückgegeben, und die KnowBe4-SAT-Konsole wurde nicht in der KnowBe4-Plattform angezeigt. Einige Hintergrundprozesse, einschließlich Benutzersynchronisation und Schulungs-E-Mails, sind in dieser Zeit ebenfalls fehlgeschlagen. Der Vorfall wurde durch eine Produktionsfreigabe verursacht, die mit einer anderen Änderung unseres Codes in Konflikt stand. Wir haben die Veröffentlichung rückgängig gemacht und die Anmeldungen in den Regionen zwischen 14:59 und 15:05 \(UTC\) wiederhergestellt. Es ist kein Datenverlust infolge dieses Problems aufgetreten. ## **Wurzelursache** Eine Codebereitstellung entfernte einen Startkonfigurationswert, um die Startzeit der Anwendung zu beschleunigen. Eine separate Komponente, die unserem Code hinzugefügt wurde, nachdem die ursprüngliche Änderung getestet wurde, berücksichtigte diesen geänderten Wert nicht. Infolgedessen hat jeder Versuch, einen Benutzerdatensatz zu speichern, einen Fehler ausgelöst, einschließlich des Updates, das Anmeldeversuche aufzeichnet. ## **Customer Impact** Kunden aus allen Regionen konnten sich nicht über SAML oder Passwort bei der KSAT-Konsole anmelden. Sie konnten auch nicht auf die Learner Experience zugreifen und konnten nicht über die KnowBe4 SAT-Konsole auf die PhishER-Konsole zugreifen. Neue Benutzererstellung, Benutzersynchronisation und Schulungs-E-Mails sind in dieser Zeit fehlgeschlagen, wurden jedoch nach dem Zurücksetzen der Bereitstellung automatisch wiederholt. ## **Abwehr und Sanierung** Wir haben festgestellt, dass die Bereitstellung einen Konfigurationswert entfernt hat, den eine andere Komponente noch benötigt. Dies wurde durch das Zurücksetzen der Veröffentlichung gemildert, und wir haben die Wiederherstellung in allen Regionen durch direkte Kontrollen und automatisierte Tests bestätigt. Wir haben auch die ursprüngliche Änderung in unserem Quellcode rückgängig gemacht und eine korrigierte Version vorbereitet, die eine Kompatibilitätskorrektur enthält, so dass die ursprüngliche Verbesserung sicher wieder eingeführt werden kann. ## **Vorbeugende Maßnahmen** Wir fügen zusätzliche Code-Verifizierungen und Tests für Bereitstellungen hinzu.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 08:47 UTCinvestigating

   Wir haben Berichte erhalten, dass das KnowBe4-E-Mail-Sicherheits-Add-in den Fehler "Das Add-in KnowBe4-E-Mail-Sicherheit verhindert, dass diese Nachricht gesendet wird" beim Senden von E-Mails anzeigt. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 13. Oktober 2026 um 11:07 UTCmonitoring

   Wir haben einen Fix für das Web Add-in-Versandfehler implementiert und überwachen die Ergebnisse, um sicherzustellen, dass keine weiteren Probleme auftreten.

3. 13. Oktober 2026 um 13:41 UTCresolved

   Dieser Vorfall wurde behoben.

4. 20. Oktober 2026 um 12:48 UTCpostmortem

   Vom Montag, dem 12. Oktober 2026, um ca. 14:25 \(UTC\), bis zum Dienstag, dem 13. Oktober 2026, um ca. 15:07 \(UTC\), hatten einige Kunden in EU-Instanzen von Prevent and Protect Schwierigkeiten, E-Mails von Microsoft Outlook zu senden. Betroffene Nachrichten wurden nicht gesendet, und das KnowBe4-E-Mail-Sicherheits-Add-In zeigte den folgenden Fehler an: "Das Add-In KnowBe4-E-Mail-Sicherheit verhindert, dass diese Nachricht gesendet wird." Dieses Problem wurde durch einen Fehler verursacht, wie eine Add-in-Version für die Veröffentlichung vorbereitet wurde, wodurch zwei leicht unterschiedliche Kopien derselben Version erzeugt wurden. Wenn Outlook das Add-In lädt, lädt es eine Reihe von Dateien herunter, die übereinstimmen müssen. In EU-Instanzen erhielt Outlook manchmal Dateien von beiden Kopien, so dass das Add-In das Laden nicht beenden konnte und die Nachricht nicht gesendet wurde. Einige Geräte haben auch den fehlgeschlagenen Download gespeichert, so dass der Fehler auf diesen Geräten fortgesetzt wurde, bis ein Fix angewendet wurde. Um dieses Problem zu beheben, korrigierte unser Team die EU-Add-In-Dateien, so dass jeder Kunde ein passendes Set erhält. Wir haben dann eine aktualisierte Version des Add-Ins für alle Regionen veröffentlicht, die alle gespeicherten Fehler gelöscht hat. Das KnowBe4-E-Mail-Sicherheits-Add-In kehrte am 13. Oktober 2026 um etwa 15:07 Uhr zur normalen Leistung zurück. Um diese Art von Problemen in Zukunft zu vermeiden, ändern wir die Art und Weise, wie Add-In-Versionen vorbereitet und veröffentlicht werden, so dass jede Version immer den gleichen Satz von Dateien produziert und jeder Kunde gleichzeitig die gleiche Version erhält. Wir ändern auch das Add-In, so dass fehlgeschlagene Downloads von Add-In-Dateien nicht auf Geräten gespeichert werden. Schließlich fügen wir Benachrichtigungen für Add-In-Ladefehler hinzu, um sie früher zu erkennen. Es ist kein Datenverlust infolge dieses Problems aufgetreten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. September 2026 um 21:10 UTCinvestigating

   Wir untersuchen derzeit ein Problem mit der verschlechterten Leistung von Prevent and Protect auf unseren US-Servern.

2. 29. September 2026 um 13:44 UTCmonitoring

   Wir haben ein Problem mit den US-Instanzen von Prevent and Protect identifiziert, das zu einer verschlechterten Leistung geführt hat. Ein Fix wurde implementiert, und wir werden dieses Problem weiterhin überwachen.

3. 2. Oktober 2026 um 10:32 UTCresolved

   Dieser Vorfall wurde behoben.

4. 6. Oktober 2026 um 15:51 UTCpostmortem

   ## **Zusammenfassung** Vom Montag, 28. September 2026, um ca. 16:00 Uhr (UTC), bis Mittwoch, 30. September 2026, um ca. 12:35 Uhr (UTC), erlebten einige Kunden einen verzögerten Postfluss und intermittierende Probleme beim Zugriff auf US-Instanzen von Prevent and Protect. Am 28. September zeigte unsere Überwachung starken Netzwerkverkehr mit Spitzenwerten pro Stunde. Einige Kunden begannen mit intermittierenden Problemen beim Zugriff auf US-Instanzen der Prevent and Protect-Konsolen. Interne Lookups, bei denen die E-Mail-Verarbeitung vom begonnenen Timing abhängt, und Nachrichten wurden als Ergebnis in die Warteschlange gestellt. Kunden haben das Problem unserem Support-Team gemeldet und wir haben eine Statusseite veröffentlicht. Die Leistung erholte sich später an diesem Tag, als der US-Verkehr abnahm. Am 29. September überprüften unsere Ingenieure die Daten des Vortages über die Mail-Gateways, die internen Dienste, von denen sie abhängig sind, und die Netzwerkschicht. E-Mail-Verzögerungen und Konsolenzugriffsprobleme kehrten kurz zurück und wurden dann gelockert, als der Netzwerkverkehr nach dem gleichen Muster wie am 28. September zurückging. Am 30. September, von ca. 12:19 bis 12:35 \(UTC\), erhöhte unser Team die Kapazität der US-Netzwerkdienste, während der Service fortgesetzt wurde. Ihre Last fiel unmittelbar nach der Änderung, und Prevent and Protect kehrte am 30. September 2026 um etwa 12:35 Uhr zur normalen Leistung zurück. Wir überwachten den Spitzenverkehr über den 30. September und den 1. Oktober und sahen keine Wiederholungen. Es ist kein Datenverlust infolge dieses Problems aufgetreten. ## **Wurzelursache** Dieses Problem wurde durch eine Kapazitätsbegrenzung in den Netzwerkdiensten verursacht, die den Datenverkehr für unsere US-Mailverarbeitungsdienste verwalten. Während des spitzenverkehrs und insbesondere während der stündlichen spitzen konnten die netzwerkdienste verbindungen nicht schnell genug verarbeiten. Dies erhöhte die verzögerung des verkehrs, der durch sie hindurchging, und führte dazu, dass einige verbindungen abfielen. Dieser Datenverkehr beinhaltete interne Anfragen, die unsere Mail-Gateways senden, um Verteilerlistenmitglieder nachzuschlagen, sodass die richtigen Richtlinien angewendet werden. Diese Anfragen unterliegen einer strengen zeitlichen Begrenzung, so dass eine langsame Suche die E-Mail-Verarbeitung nicht auf unbestimmte Zeit aufhalten kann. Als die Netzwerkdienste Anfragen über dieses Limit hinaus verzögerten, schlugen sie fehl. Infolgedessen verlangsamte sich die E-Mail-Verarbeitung und die Nachrichten wurden in die Warteschlange gestellt. Zwei Faktoren machten das Problem schlimmer und schwieriger zu identifizieren. Erstens nutzten einige interne Anfragen auch diese Netzwerkdienste und waren von der Kapazitätsbegrenzung betroffen. Zweitens begannen sich die Netzwerkdienste zu verschlechtern, bevor ihre Computernutzung ein Niveau erreichte, das normalerweise ein Problem signalisieren würde. Die Standard-Compute-Überwachung hat die Netzwerksättigung nicht erfasst, daher dauerte die Identifizierung der Ursache länger. Die Suche nach einem sicheren Weg, um die Kapazität zu erhöhen, ohne den Service zu unterbrechen, dauerte ebenfalls einige Zeit, weshalb der Fix am 30. September angewendet wurde. ## **Abwehr und Sanierung** Wir fanden heraus, dass die US-Netzwerkdienste nicht genug Kapazität hatten, um den Spitzenverkehr zu bewältigen. Wir haben dies gemildert, indem wir ihre Kapazität so erhöht haben, dass der Service während des gesamten Wandels am Laufen gehalten wurde. Nach der Kapazitätserhöhung behandelten die Netzwerkdienste den Spitzenverkehr ohne weitere Probleme. Wir fanden auch heraus, dass die Computernutzung allein kein zuverlässiges Zeichen für die Netzwerksättigung war. Wir haben unser Monitoring erweitert, um Netzwerkgesundheitsindikatoren zusätzlich zur Berechnungsnutzung zu verfolgen. Schließlich fanden wir es schwierig zu finden, wo gescheiterte interne Anfragen zusammenbrachen. Wir haben Protokollierung hinzugefügt, die zeigt, wo interne Anfragen fehlschlagen und Zeit aus. ## **Customer Impact** Während des Spitzenverkehrs in den USA am 28. und 29. September erlebten einige Kunden Verzögerungen bei der Verarbeitung und Zustellung eingehender und ausgehender Post über Prevent and Protect. Nachrichten, die an Verteilerlisten adressiert sind, wurden möglicherweise langsamer verarbeitet, während Lookups erneut getestet wurden. Einige Kunden hatten auch intermittierende Schwierigkeiten, sich bei der US-Konsole anzumelden oder diese zu verwenden. Die Auswirkungen verringerten sich jeden Tag, als der US-Verkehr abnahm, und die in die Warteschlange gestellte Post wurde verarbeitet, sobald die Kapazität wiederhergestellt war. Nach der Änderung am 30. September sahen wir keine weitere Verschlechterung während des Spitzenverkehrs. ## **Vorbeugende Maßnahmen** Um diese Art von Problemen in Zukunft zu verhindern, haben wir die Kapazität der US-Netzwerkdienste erhöht und unser Monitoring erweitert, um Netzwerkgesundheitsindikatoren zusätzlich zur Berechnungsnutzung zu verfolgen. Wir haben auch Protokollierung hinzugefügt, um die Sichtbarkeit von fehlgeschlagenen internen Anfragen zu verbessern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. September 2026 um 17:53 UTCinvestigating

   Wir haben ein Problem mit Protect identifiziert, das zu einer verschlechterten Leistung geführt hat, und unser Engineering-Team prüft eine Lösung.

2. 24. September 2026 um 18:39 UTCmonitoring

   Wir haben ein Problem mit Protect identifiziert, das zu einer verschlechterten Leistung geführt hat. Es wurde ein Fix implementiert, und wir werden dieses Problem weiterhin überwachen.

3. 24. September 2026 um 19:57 UTCinvestigating

   Wir haben ein Problem mit Protect & Prevent identifiziert, das zu einer verschlechterten Leistung geführt hat, und unser Engineering-Team prüft eine Lösung.

4. 24. September 2026 um 21:46 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 25. September 2026 um 09:16 UTCresolved

   Dieser Vorfall wurde behoben.

6. 6. Oktober 2026 um 15:51 UTCpostmortem

   ## **Zusammenfassung** Von Donnerstag, 24. September 2026, um ca. 17:07 \(UTC\), bis Freitag, 25. September 2026, um 09:16 \(UTC\), erlebten einige Kunden intermittierende Langsamkeit, Fehler und verzögerten Postfluss für US-Instanzen von Protect and Prevent. Am 24. September hat ein ungewöhnlich hoher Anstieg des E-Mail-Verkehrs die Netzwerkdienste, die den Datenverkehr für unsere US-Mailverarbeitung verwalten, nachhaltig belastet. Unsere Überwachung alarmierte uns um ca. 17:07 \(UTC\). Einige Kunden sahen langsamen oder intermittierenden Zugriff auf Protect und gelegentliche Fehler beim Laden von Seiten oder erweiterten Optionen. Der Zugriff war inkonsistent, so dass einige Kunden Protect verwenden konnten, während andere Fehler sahen. Die e-mail-verarbeitung durch us-instanzen verlangsamte sich, und einige nachrichten verzögerten sich oder erschienen nicht im moderationsposteingang, wenn erwartet. Die Leistung schien sich zu verbessern, so dass wir unsere Statusseite auf Monitoring um 18:39 \(UTC\) verschoben haben. Das Problem trat später erneut auf, und die Kunden berichteten unserem Support-Team von anhaltender Langsamkeit. Um 19:57 \(UTC\) haben wir die Mitteilung zurück zu Investigating verschoben und sie erweitert, um auch Prevent einzubeziehen, da die Auswirkungen klarer wurden. Unser Team überwachte die betroffenen Systeme, während das erhöhte Postvolumen nachließ. Da die Belastung der Netzwerkdienste wieder normal war, erholte sich die E-Mail-Verarbeitung und die E-Mail-Warteschlangen wurden über Nacht wieder normal. Wir haben bestätigt, dass Protect normal geladen wurde und dass Testnachrichten erneut zugestellt wurden, und dann die Überwachung fortgesetzt. Protect and Prevent kehrte am 25. September 2026 um 09:16 Uhr zur normalen Leistung zurück. Es ist kein Datenverlust infolge dieses Problems aufgetreten. ## **Wurzelursache** Dieses Problem wurde durch einen ungewöhnlich großen Anstieg des E-Mail-Verkehrs verursacht. Das erhöhte Volumen belastete die Netzwerkdienste, die den Datenverkehr für unsere US-Mailverarbeitung verwalten, nachhaltig. Diese Netzwerkdienste arbeiten innerhalb fester Kapazitätsgrenzen, und ihre Kapazität konnte während des Spikes nicht hochskaliert werden. Weil sie mit dem Anstieg nicht mithalten konnten, verlangsamten sie sich und einige Verarbeitungen scheiterten intermittierend. Infolgedessen wurde ein großes Volumen an E-Mails in der US-Mailverarbeitung in die Warteschlange gestellt, einige Seiten und Aktionen in Protect gaben Fehler zurück, und einige Nachrichten wurden verzögert oder erschienen nicht im Moderationsposteingang, wenn erwartet. Zwei Faktoren machten das Problem schwieriger zu verwalten. Erstens, weil der Zugriff intermittierend fehlschlug, waren einige Überprüfungen erfolgreich, während die Kunden weiterhin Fehler sahen, was die Bestätigung der Wiederherstellung erschwerte. Zweitens zeigte unser Monitoring die Spitzenlast auf den Netzwerkdiensten deutlicher als die aktuelle Last, was es schwieriger machte, in Echtzeit zu beurteilen, ob die Last noch erhöht war. ## **Abwehr und Sanierung** Wir fanden heraus, dass die Netzwerkdienste, die die US-Mailverarbeitung abwickeln, ihre festen Kapazitätsgrenzen während des Traffic-Spikes erreicht hatten und ihre Kapazität während der Veranstaltung nicht erhöht werden konnte. Unser Team überwachte die betroffenen Systeme, während das erhöhte Postvolumen nachließ und die Netzwerkdienstlast wieder normal wurde. Die E-Mail-Verarbeitung wurde dann wiederhergestellt und die in die Warteschlange gestellte E-Mail wurde verarbeitet. Da sich das Problem zuvor zu verbessern schien, bevor es sich wiederholte, bestätigten wir die Genesung auf verschiedene Weise, bevor wir den Vorfall lösten. Wir bestätigten, dass Protect normal geladen wurde, dass Testnachrichten über die US-Mail-Verarbeitung zugestellt wurden und dass Supportanfragen normal voranschritten. Wir haben auch über Nacht überwacht und keine neuen Berichte von Kunden über US-Instanzen erhalten. ## **Customer Impact** Einige Kunden hatten langsamen oder intermittierenden Zugriff auf Protect und sahen gelegentlich Fehler beim Laden von Seiten oder erweiterten Optionen. Die E-Mail-Verarbeitung durch US-Instanzen wurde für Protect and Prevent verzögert. In einigen fällen wurden nachrichten verzögert oder erschienen nicht im moderationsposteingang, wenn erwartet. Kunden, deren E-Mails verschlüsselt, entschlüsselt oder moderiert werden, während sie unsere US-Mail-Verarbeitung durchlaufen, waren eher betroffen. Die meisten Protect-Kunden, die das Add-In verwenden, waren von den Verzögerungen bei der E-Mail-Verarbeitung nicht betroffen. Die Protect and Prevent-Konsolen blieben verfügbar, obwohl einige Konsolenaktionen von der langsameren E-Mail-Verarbeitung betroffen waren. ## **Vorbeugende Maßnahmen** Um diese Art von Problemen in Zukunft zu verhindern, verbessern wir unsere Überwachung von ungewöhnlichen Anstiegen des E-Mail-Volumens. Wir verbessern auch unsere Überwachung, um die aktuelle Belastung unserer Netzwerkdienste anzuzeigen, nicht nur Spitzenwerte. Darüber hinaus prüfen wir Möglichkeiten, unsere Netzwerkkapazität bei plötzlichen Verkehrsspitzen dynamischer zu skalieren, und bewerten längerfristige Verbesserungen der Netzwerkinfrastruktur, die die US-Mail-Verarbeitung übernimmt. Seitdem haben wir auch die Kapazität der US-Netzwerkdienste als Reaktion auf [einen späteren Vorfall] (https://status.knowbe4.com/incidents/9wc6rjm8g70v) erhöht.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 09:52 UTCidentified

   Wir haben Berichte von Benutzern erhalten, die beim Anmelden Fehlermeldungen "Zugriff verweigert" erhalten haben. Wir haben das Problem identifiziert und arbeiten an der Implementierung einer Lösung und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 23. September 2026 um 10:57 UTCmonitoring

   Das Problem wurde identifiziert und ein Fix wurde implementiert und wird diese Seite aktualisieren, wenn wir weitere Informationen haben.

3. 23. September 2026 um 14:58 UTCresolved

   Dieser Vorfall wurde erfolgreich behoben und alle Systeme sind voll funktionsfähig.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 09:00 UTCinvestigating

   Wir haben Berichte erhalten, dass einige Benutzer nicht in der Lage sind, Webformular-Einreichungen erfolgreich einzureichen. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 23. September 2026 um 10:47 UTCidentified

   Das Problem wurde identifiziert und ein Fix wurde implementiert. Ein Update mit weiteren Informationen wird entsprechend folgen.

3. 23. September 2026 um 10:58 UTCmonitoring

   Das Problem wurde identifiziert und ein Fix wurde implementiert und wird diese Seite aktualisieren, wenn wir weitere Informationen haben.

4. 23. September 2026 um 14:58 UTCresolved

   Dieser Vorfall wurde erfolgreich behoben und alle Systeme sind voll funktionsfähig.

5. 20. Oktober 2026 um 15:53 UTCpostmortem

   Am Mittwoch, den 23. September 2026, von ca. 08:15 bis 11:18 \(UTC\), erlebten einige Kunden Langsamkeit und fehlgeschlagene Formulareinreichungen in britischen Instanzen von Secure Webforms. Dieses Problem wurde durch die Leistungsgrenzen der Datenbank in der britischen Produktionsumgebung nach einer kürzlichen Änderung verursacht. Eine Datenbankeinstellung führte auch dazu, dass einige Abfragen ineffizient ausgeführt wurden. Infolgedessen erhöhten sich die Antwortzeiten und einige Formulareinreichungen scheiterten. Um dieses Problem zu beheben, hat unser Team eine Hintergrundsynchronisierungsaufgabe vorübergehend angehalten, um die Belastung zu reduzieren, die Datenbankeinstellungen angepasst, um die Abfrageeffizienz zu verbessern, und den Speicherdurchsatz erhöht. Secure Webforms kehrte zur normalen Leistung um 11:18 \(UTC\) zurück. Um diese Art von Problemen in Zukunft zu vermeiden, fügen wir zusätzliche Überwachung für die Datenbankbandbreite hinzu. Wir verbessern auch die Effizienz der Hintergrundsynchronisationsaufgabe. Es ist kein Datenverlust infolge dieses Problems aufgetreten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. September 2026 um 09:32 UTCinvestigating

   Wir haben Berichte erhalten, dass Benutzer keine E-Mails über Web Access (Secure Message Portal) in der Region Großbritannien senden können, mit Fehler "503 Service Unavailable". Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 21. September 2026 um 14:36 UTCmonitoring

   Wir haben einen Fix implementiert und überwachen die Ergebnisse.

3. 21. September 2026 um 14:38 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

4. 22. September 2026 um 08:27 UTCresolved

   Dieser Vorfall wurde erfolgreich behoben und alle Systeme sind voll funktionsfähig.

5. 8. Oktober 2026 um 13:45 UTCpostmortem

   Am Montag, den 21. September 2026, von ca. 08:55 bis Dienstag, den 22. September 2026, um ca. 14:30 \(UTC\), erlebten einige Benutzer Fehler und konnten keine E-Mails über Web Access \(Secure Message Portal\) in der Region Großbritannien senden. Dieser Vorfall wurde durch einen Konfigurationsfehler während einer Datenbankaktualisierung verursacht, der zu einer Unterbrechung des Dienstes führte. Um dieses Problem zu beheben, haben wir die Konfiguration zurückgesetzt, und Web Access kehrte am 22. September 2026 bis 14:30 \(UTC\) zur normalen Leistung zurück. Um diese Art von Problemen in Zukunft zu vermeiden, überprüfen und aktualisieren wir unsere Datenbankkonfiguration. Es ist kein Datenverlust infolge dieses Problems aufgetreten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. September 2026 um 11:07 UTCinvestigating

   Wir haben Berichte erhalten, dass Benutzer sich nicht bei den DE- und UK-Instanzen von KSAT anmelden können. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 18. September 2026 um 16:48 UTCresolved

   Dieser Vorfall wurde behoben.

3. 8. Oktober 2026 um 14:07 UTCpostmortem

   ## **Zusammenfassung** Am 17. September 2026 archivierte ein Hintergrundjob eine große Benutzergruppe und lief als eine einzige unbegrenzte Datenbanktransaktion. Diese Transaktion sperrte eine große Anzahl von Benutzerzeilen, was dazu führte, dass die Anmeldungen in der US-Region ausfielen, weil sie in dieselbe Tabelle schreiben. Nach dem Erreichen eines Plattformausführungslimits wurde der Auftrag beendet und in 15-Minuten-Intervallen fünfmal automatisch wiederholt, was zu einem 75-minütigen Ausfall führte. Um das Problem zu beheben, haben wir einen Fix bereitgestellt, der die Logins vom Schloss entkoppelt. Wir haben dann einen Follow-up-Fix für eine durch die Login-Änderung eingeführte Regression sowie für den Archivierungsjob bereitgestellt. ## **Was geschah ** Eine vorherige Änderung verlagerte die Aktion "Alle Benutzer archivieren" von einer synchronen Timeout-Webanforderung in einen unbegrenzten Hintergrundjob. Wenn eine große Benutzergruppe archiviert wurde, löste dies den neuen Hintergrundjob aus. Der Job sperrte alle betroffenen Benutzerzeilen in einer einzigen Transaktion, indem er pro Benutzer schreibt und einen synchronen externen Serviceanruf vor dem Begehen durchführte. Login-Versuche, die in die gleiche Tabelle schreiben, wurden hinter dem gesperrten Job in die Warteschlange gestellt und für US-Benutzer zeitlich begrenzt. Als der Job ein 15-minütiges Ausführungslimit für die Plattform erreichte, wurde er mitten in der Transaktion beendet, die Transaktion zurückgesetzt und der Job wurde in die Warteschlange zurückgestellt. Dieser Zyklus trat fünfmal auf, was zu einem 75-minütigen Ausfall führte. Wenn Fehler intern um 22:35 \(UTC\) erkannt wurden, wurde ein Vorfall erklärt, und ein Ingenieur wurde aufgefordert, zu antworten. Die Minderung zur Entkopplung der Schreibaktion vom Login-Fluss wurde bei ca. 23:44 \(UTC\) eingesetzt. Die Minderung selbst führte zu einer Regression: Jeder Benutzer in einer Region, der zuvor ein Passwort falsch eingegeben hatte, konnte sich nicht mehr anmelden, da Resets für fehlgeschlagene Anmeldeversuche versuchten, in eine schreibgeschützte Datenbank zu schreiben. Bis 09:17 Uhr (UTC) am 18. September 2026 wurde der Fix für diese Regression in allen Regionen eingesetzt. Das ursprüngliche US-Archiv-Jobproblem wiederholte sich zweimal zwischen 13:45 und 14:05 \(UTC\), bevor um ca. 15:00 \(UTC\) ein permanenter Fix bereitgestellt wurde. Der Vorfall wurde am 18. September 2026 um 19:12 Uhr (UTC) vollständig gelöst. ## **Wurzelursache** Ein unbegrenzter Hintergrundjob für Einzeltransaktionen für die Archivierung von Großgruppennutzern enthielt exklusive Sperren für viele betroffene Zeilen und blockierte den eigenen Zeilenschreibvorgang des Anmeldevorgangs. Eine vorherige Änderung, um diesen Vorgang von einem Webanforderungs-Timeout und in einen Hintergrundjob zu verschieben, entfernte die einzige verbleibende Begrenzung seiner Dauer. Das 15-Minuten-Ausführungslimit der Plattform löste dann automatische Kill-and-Redeliver-Zyklen aus, wiederholte den Sperrstreit fünfmal und führte zu einem 75-Minuten-Ausfallfenster. ## **Findings und Mitigations** Wir fanden heraus, dass die unbegrenzte Archivtransaktion eine große Anzahl betroffener Benutzerzeilen sperrte und andere Tabellen schreibt blockierte. Dies wurde kurzfristig gemildert, indem die Schreibabhängigkeit des Anmeldeprozesses von der betroffenen Tabelle entkoppelt und dann langfristig durch Korrektur des Archivauftrags behoben wurde. Wir haben auch festgestellt, dass unkoordinierte Arbeitergleichheit die Lock-Konkurrenz verstärkt. Dies wurde kurzfristig gemildert, indem die Gleichzeitigkeit der Arbeitnehmer manuell reduziert wurde. Die langfristige Fixierung zur Staffelung und Serialisierung dieser Jobs ist geplant. Schließlich fanden wir heraus, dass die Login-Fix-Regression für Benutzer mit früheren fehlgeschlagenen Versuchen Ausfälle in allen Regionen verursachte, da Schreibvorgänge von einer schreibgeschützten Datenbank abgelehnt wurden. Dies wurde durch eine gezielte Codeänderung behoben, die in allen Regionen implementiert und verifiziert wurde. ## **Vorbeugende Maßnahmen** Wir verbessern unsere Großgruppenarchivierung, indem wir sie begrenzen, sie in kleinen, engagierten Batches verarbeiten und externe Anrufe außerhalb der Datenbanktransaktion halten. Wir fügen auch einen Änderungscheck zu einem bestimmten Hintergrundarbeiter hinzu, um Schreibvorgänge zu überspringen, die nichts ändern. Schließlich fügen wir direkte Warnungen für das Alter von Datenbanktransaktionen und Bereinigungsverzögerungen hinzu, zusätzlich zu periodischen indirekten Überprüfungen. ## **Customer Impact und Recovery** Login-Ausfälle dauerten in der US-Region etwa 75 Minuten. Zwei kurze, nur US-Rezidive traten am nächsten Morgen auf und wurden innerhalb von Minuten manuell gelöscht. Einige Admin-Aktionen wie die Benutzerverwaltung waren ebenfalls betroffen. Die Logins der Partner waren nicht betroffen. Die sekundäre Regression dauerte etwa 10 Stunden und betraf alle Regionen für Benutzer, die zuvor einen Anmeldeversuch nicht bestanden hatten. Am Nachmittag des 18. September wurde die vollständige Genesung in allen Regionen bestätigt und die Statusseite als gelöst markiert. Es ist kein Datenverlust infolge dieses Problems aufgetreten. ## **Schlussfolgerung** Eine einzige unbegrenzte Hintergrundtransaktion, kombiniert mit einem automatischen Retry-Mechanismus, verursachte einen Login-Ausfall in der US-Region. Der spezifische auslösende Job und sein Wiederholungsverhalten wurden behoben, und die Anmeldung hängt nicht mehr vom umkämpften Schreibpfad ab. Eine Regression des gleichen Vorfalls und zwei kleinere Rezidive wurden jeweils innerhalb von Stunden behoben. Verbleibende vorbeugende Arbeiten, einschließlich der Koordination der Mitarbeiter und der Überwachung von Datenbanktransaktionen, werden oben nachverfolgt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. September 2026 um 22:44 UTCinvestigating

   Wir haben Berichte erhalten, dass Benutzer sich nicht bei der US-Instanz von KSAT anmelden können. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 18. September 2026 um 01:28 UTCmonitoring

   Wir haben einen Fix implementiert und überwachen die Ergebnisse, um sicherzustellen, dass keine weiteren Probleme auftreten.

3. 18. September 2026 um 14:02 UTCinvestigating

   Wir haben neue Berichte erhalten, dass Benutzer sich nicht bei der US-Instanz von KSAT anmelden können. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

4. 18. September 2026 um 16:47 UTCresolved

   Dieser Vorfall wurde behoben.

5. 5. Oktober 2026 um 21:16 UTCpostmortem

   ## **Zusammenfassung** Am 17. September 2026 archivierte ein Hintergrundjob eine große Benutzergruppe und lief als eine einzige unbegrenzte Datenbanktransaktion. Diese Transaktion sperrte eine große Anzahl von Benutzerzeilen, was dazu führte, dass die Anmeldungen in der US-Region ausfielen, weil sie in dieselbe Tabelle schreiben. Nach dem Erreichen eines Plattformausführungslimits wurde der Auftrag beendet und in 15-Minuten-Intervallen fünfmal automatisch wiederholt, was zu einem 75-minütigen Ausfall führte. Um das Problem zu beheben, haben wir einen Fix bereitgestellt, der die Logins vom Schloss entkoppelt. Wir haben dann einen Follow-up-Fix für eine durch die Login-Änderung eingeführte Regression sowie für den Archivierungsjob bereitgestellt. ## **Was geschah ** Eine vorherige Änderung verlagerte die Aktion "Alle Benutzer archivieren" von einer synchronen Timeout-Webanforderung in einen unbegrenzten Hintergrundjob. Wenn eine große Benutzergruppe archiviert wurde, löste dies den neuen Hintergrundjob aus. Der Job sperrte alle betroffenen Benutzerzeilen in einer einzigen Transaktion, indem er pro Benutzer schreibt und einen synchronen externen Serviceanruf vor dem Begehen durchführte. Login-Versuche, die in die gleiche Tabelle schreiben, wurden hinter dem gesperrten Job in die Warteschlange gestellt und für US-Benutzer zeitlich begrenzt. Als der Job ein 15-minütiges Ausführungslimit für die Plattform erreichte, wurde er mitten in der Transaktion beendet, die Transaktion zurückgesetzt und der Job wurde in die Warteschlange zurückgestellt. Dieser Zyklus trat fünfmal auf, was zu einem 75-minütigen Ausfall führte. Wenn Fehler intern um 22:35 \(UTC\) erkannt wurden, wurde ein Vorfall erklärt, und ein Ingenieur wurde aufgefordert, zu antworten. Die Minderung zur Entkopplung der Schreibaktion vom Login-Fluss wurde bei ca. 23:44 \(UTC\) eingesetzt. Die Minderung selbst führte zu einer Regression: Jeder Benutzer in einer Region, der zuvor ein Passwort falsch eingegeben hatte, konnte sich nicht mehr anmelden, da Resets für fehlgeschlagene Anmeldeversuche versuchten, in eine schreibgeschützte Datenbank zu schreiben. Bis 09:17 Uhr (UTC) am 18. September 2026 wurde der Fix für diese Regression in allen Regionen eingesetzt. Das ursprüngliche US-Archiv-Jobproblem wiederholte sich zweimal zwischen 13:45 und 14:05 \(UTC\), bevor um ca. 15:00 \(UTC\) ein permanenter Fix bereitgestellt wurde. Der Vorfall wurde am 18. September 2026 um 19:12 Uhr (UTC) vollständig gelöst. ## **Wurzelursache** Ein unbegrenzter Hintergrundjob für Einzeltransaktionen für die Archivierung von Großgruppennutzern enthielt exklusive Sperren für viele betroffene Zeilen und blockierte den eigenen Zeilenschreibvorgang des Anmeldevorgangs. Eine vorherige Änderung, um diesen Vorgang von einem Webanforderungs-Timeout und in einen Hintergrundjob zu verschieben, entfernte die einzige verbleibende Begrenzung seiner Dauer. Das 15-Minuten-Ausführungslimit der Plattform löste dann automatische Kill-and-Redeliver-Zyklen aus, wiederholte den Sperrstreit fünfmal und führte zu einem 75-Minuten-Ausfallfenster. ## **Findings und Mitigations** Wir fanden heraus, dass die unbegrenzte Archivtransaktion eine große Anzahl betroffener Benutzerzeilen sperrte und andere Tabellen schreibt blockierte. Dies wurde kurzfristig gemildert, indem die Schreibabhängigkeit des Anmeldeprozesses von der betroffenen Tabelle entkoppelt und dann langfristig durch Korrektur des Archivauftrags behoben wurde. Wir haben auch festgestellt, dass unkoordinierte Arbeitergleichheit die Lock-Konkurrenz verstärkt. Dies wurde kurzfristig gemildert, indem die Gleichzeitigkeit der Arbeitnehmer manuell reduziert wurde. Die langfristige Fixierung zur Staffelung und Serialisierung dieser Jobs ist geplant. Schließlich fanden wir heraus, dass die Login-Fix-Regression für Benutzer mit früheren fehlgeschlagenen Versuchen Ausfälle in allen Regionen verursachte, da Schreibvorgänge von einer schreibgeschützten Datenbank abgelehnt wurden. Dies wurde durch eine gezielte Codeänderung behoben, die in allen Regionen implementiert und verifiziert wurde. ## **Vorbeugende Maßnahmen** Wir verbessern unsere Großgruppenarchivierung, indem wir sie begrenzen, sie in kleinen, engagierten Batches verarbeiten und externe Anrufe außerhalb der Datenbanktransaktion halten. Wir fügen auch einen Änderungscheck zu einem bestimmten Hintergrundarbeiter hinzu, um Schreibvorgänge zu überspringen, die nichts ändern. Schließlich fügen wir direkte Warnungen für das Alter von Datenbanktransaktionen und Bereinigungsverzögerungen hinzu, zusätzlich zu periodischen indirekten Überprüfungen. ## **Customer Impact und Recovery** Login-Ausfälle dauerten in der US-Region etwa 75 Minuten. Zwei kurze, nur US-Rezidive traten am nächsten Morgen auf und wurden innerhalb von Minuten manuell gelöscht. Einige Admin-Aktionen wie die Benutzerverwaltung waren ebenfalls betroffen. Die Logins der Partner waren nicht betroffen. Die sekundäre Regression dauerte etwa 10 Stunden und betraf alle Regionen für Benutzer, die zuvor einen Anmeldeversuch nicht bestanden hatten. Am Nachmittag des 18. September wurde die vollständige Genesung in allen Regionen bestätigt und die Statusseite als gelöst markiert. Es ist kein Datenverlust infolge dieses Problems aufgetreten. ## **Schlussfolgerung** Eine einzige unbegrenzte Hintergrundtransaktion, kombiniert mit einem automatischen Retry-Mechanismus, verursachte einen Login-Ausfall in der US-Region. Der spezifische auslösende Job und sein Wiederholungsverhalten wurden behoben, und die Anmeldung hängt nicht mehr vom umkämpften Schreibpfad ab. Eine Regression des gleichen Vorfalls und zwei kleinere Rezidive wurden jeweils innerhalb von Stunden behoben. Verbleibende vorbeugende Arbeiten, einschließlich der Koordination der Mitarbeiter und der Überwachung von Datenbanktransaktionen, werden oben nachverfolgt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 17:47 UTCidentified

   Wir haben ein Problem identifiziert, das Anmelde- und Zugriffsprobleme für Konten in unserer britischen Instanz verursacht.

2. 16. September 2026 um 18:16 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 16. September 2026 um 20:58 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 11. September 2026 um 12:43 UTCresolved

   Am 8. September haben wir darauf aufmerksam gemacht, dass eingehende HTML-E-Mails in Classic Outlook aufgrund eines routinemäßigen HTML-Bibliotheks-Upgrades in Defends schädlicher Code-Entfernungs-Engine teilweise oder leer gerendert wurden und mit der alten Word-Rendering-Engine von Classic Outlook interagieren. Neue Outlook und Outlook im Web waren nicht betroffen. Dies war ein reines Anzeigeproblem: Es wurde keine E-Mail verzögert, verloren oder kompromittiert, und die Bedrohungserkennung blieb voll aktiv. Engineering hat das Update zurückgesetzt, um das normale Rendering wiederherzustellen. Wenn Sie das Entfernen von Schadcodes während dieses Fensters vorübergehend deaktiviert haben, aktivieren Sie es bitte erneut, um einen vollständigen Schutz zu gewährleisten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 4. September 2026 um 10:53 UTCinvestigating

   Wir haben Berichte über ein Problem mit der Zustellung der E-Mail-Verifizierung MFA für Workspace erhalten. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 4. September 2026 um 14:24 UTCmonitoring

   Wir haben Berichte erhalten, dass das Problem mit der Zustellung der E-Mail-Verifizierung MFA für Workspace von Microsoft gemildert wurde, und wir überwachen die Ergebnisse.

3. 7. September 2026 um 08:25 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. August 2026 um 16:19 UTCinvestigating

   Wir haben ein Problem identifiziert, bei dem Benutzer Verzögerungen bei der Verarbeitung von Nachrichten feststellen können, und unser Engineering-Team prüft eine Lösung.

2. 26. August 2026 um 16:46 UTCmonitoring

   Unser Engineering-Team hat eine Korrektur für das Problem implementiert, das zu Verzögerungen bei der Nachrichtenverarbeitung in PhishER führt, und wir überwachen die Ergebnisse.

3. 26. August 2026 um 19:51 UTCresolved

   Unser Engineering-Team hat eine Korrektur für das Problem implementiert, das zu Verzögerungen bei der Nachrichtenverarbeitung in PhishER führt.

4. 16. Oktober 2026 um 20:36 UTCpostmortem

   ## **Zusammenfassung** Während einer routinemäßigen Bereitstellung am 26. August 2026 entfernte ein Infrastrukturmanagement-Framework unerwartet sowohl die primären Warteschlangen für die Nachrichtenverarbeitung als auch die sekundären Warteschlangen, in denen Nachrichten gespeichert waren, die nicht verarbeitet werden konnten. Dies führte zu einer vorübergehenden Unterbrechung der eingehenden E-Mail-Zustellung an die Posteingänge der PhishER-Kunden. Es ist kein Datenverlust infolge dieses Problems aufgetreten. ## **Wurzelursache** Am 24. August 2026 ließ eine interne Konfigurationsänderung die Live-Konfigurationsdatensätze mit unserem Code nicht synchronisieren. Ein späteres Code-Update hat diese Datensätze nicht rückgängig gemacht. Als eine routinemäßige Produktionsbereitstellung am 26. August 2026 lief, enthielt der aktive Konfigurationscode nicht die verschobenen Ressourceneinträge. Infolgedessen behandelte der Einsatz die aktiven Warteschlangen als nicht verwaltete Ressourcen und entfernte sie. ## **Abwehr und Sanierung** Die automatisierte Überwachung warnte uns vor einem Rückgang der Nachrichtenverarbeitung, und ein Incident Response-Team wurde zusammengestellt. Wir stellten fest, dass die Warteschlangen gelöscht wurden. Dies wurde kurzfristig abgemildert, indem die betroffenen Produktionsjobs erneut ausgeführt wurden, um die fehlenden Warteschlangen wiederherzustellen. Wir haben dann überprüft, dass die Echtzeit-E-Mail-Verarbeitung wieder aufgenommen wurde. Schließlich haben wir die E-Mail-Nutzlasten, die während des Ausfalls im Cloud-Speicher gespeichert wurden, erneut in die Posteingänge der Kunden abgespielt. ## ** Timeline ** Alle Zeiten sind in UTC. * ** 24. August 2026, 18:41:** Eine interne Konfigurationsänderung schrieb aktualisierte Ressourceneinträge in die Live-Produktionskonfiguration. * ** 26. August 2026, 15:15:** Eine Produktionsbereitstellung entfernte die eingehenden Warteschlangen und die Warteschlangen, in denen Nachrichten gespeichert waren, die in der Produktion nicht verarbeitet werden konnten, wodurch die E-Mail-Zustellung in die Posteingänge der Kunden gestoppt wurde. * ** 26. August 2026, 15:59:** Unsere automatisierte Überwachung alarmierte das Engineering-Team, dass null Nachrichten verarbeitet wurden, und ein Incident Response-Team wurde gepaget. * ** 26. August 2026, 16:01:** Wir bestätigten, dass die Warteschlangen gelöscht wurden und verifizierten, dass eingehende E-Mail-Nutzlasten noch sicher gespeichert wurden. * ** 26. August 2026, 16:15:** Wir haben die Konfigurationsfehlanpassung als primäre Ursache identifiziert. * ** 26. August 2026, 16:25:** Unser Team führte die betroffenen Produktionsjobs durch und die Warteschlangen wurden neu erstellt. * ** 26. August 2026, 18:44:** Unsere automatisierte Wiederholung beendete die Zustellung aller hinterlegten E-Mails an die Posteingänge der Kunden. ## **Vorbeugende Maßnahmen** Um diese Art von Problemen in Zukunft zu vermeiden, haben wir einen Live-Konfigurationsschritt aus Pre-Merge-Checks entfernt und die Bereitstellungsplanung von Produktionsänderungen getrennt. Wir haben auch automatisierte Überprüfungen hinzugefügt, um den Zustand der Warteschlange nach Abschluss der Veröffentlichungen zu bestätigen. ## **Customer Impact** Von 15:15 bis 16:25 Uhr (UTC) am 26. August 2026 wurden eingehende E-Mails, die an PhishER gesendet wurden, nicht in Posteingänge des Kunden verarbeitet. Die eingehenden E-Mail-Nutzlasten wurden während der gesamten Störung sicher im Cloud-Speicher gespeichert. Nachdem die Warteschlangen wiederhergestellt wurden, lieferte eine automatisierte Wiederholung E-Mails an die Posteingänge der Kunden. Alle backlogged Nachrichten wurden von 18:44 \(UTC\) geliefert. Es gingen keine Kunden-E-Mail-Daten infolge dieses Problems verloren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. August 2026 um 08:52 UTCinvestigating

   Wir haben Berichte erhalten, dass der Gmail Phish Alert Button den Fehler "[reportPhishAttempt()" anzeigt. Es ist ein interner Fehler aufgetreten. Bitte versuchen Sie es noch einmal." bei der Meldung von Phish. " Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 21. August 2026 um 12:03 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 21. August 2026 um 13:08 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 21. August 2026 um 14:57 UTCresolved

   Dieser Vorfall wurde behoben.

5. 26. August 2026 um 15:55 UTCpostmortem

   Am Freitag, den 21. August 2026, von ca. 05:20 bis 12:55 \(UTC\), erlebten einige Kunden intermittierende Ausfälle, wenn sie das Gmail Phish Alert Button Add-In verwendeten, um verdächtige E-Mails zu melden, und erhielten die Nachricht "Ein interner Fehler ist aufgetreten" anstelle einer erfolgreichen Berichtsbestätigung. Das Problem betraf Kunden in allen Regionen, wobei sich das höchste Fehlervolumen auf die Serviceregionen EU-West und USA-Ost konzentrierte. Dieses Problem wurde durch eine Störung in einem Caching-Dienst auf der Google Apps Script-Plattform verursacht, auf die sich das Add-In stützt, um die Sitzungskonfiguration pro Benutzer zu speichern. Der Dienst begann, zeitweise leere Ergebnisse beim Lesen zurückzugeben, während er immer noch neue Schreibvorgänge akzeptierte, was dazu führte, dass betroffene Berichtseinreichungen fehlschlugen. KnowBe4 hat Google direkt engagiert und zwischen ca. 12:19 und 12:39 \(UTC\) einen formellen Fehlerbericht eingereicht. Das Fehlervolumen ging kurz darauf stark zurück, als der herstellerseitige Zustand gelöscht wurde, und der Gmail Phish Alert Button kehrte um etwa 12:55 \(UTC\) zur normalen Leistung zurück. Um diese Art von Problem in Zukunft zu verhindern, arbeiten wir weiterhin mit Google zusammen, um die Lösung des zugrunde liegenden Caching-Defekts zu verfolgen. Es ist kein Datenverlust infolge dieses Problems aufgetreten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. August 2026 um 14:29 UTCinvestigating

   Wir untersuchen ein Problem, das dazu führt, dass ein Non-Delivery Report (NDR) zurückgegeben wird, wenn eine Nachricht über den Phish Alert Button gemeldet wird und "Send Us a Copy" in den Kontoeinstellungen aktiviert ist

2. 18. August 2026 um 15:26 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 18. August 2026 um 20:14 UTCresolved

   Dieser Vorfall wurde behoben.

4. 30. September 2026 um 20:06 UTCpostmortem

   Am Dienstag, den 18. August 2026, von ca. 14:10 bis 14:55 \(UTC\), erhielten Kunden, die den Phish Alert Button \(PAB\) mit der aktivierten **Send Us a Copy**-Funktion benutzten, Nicht-Lieferungsberichte für das **Send Us a Copy**-Postfach. Dieses Problem wurde durch eine Konfigurationsänderung der gemeinsamen E-Mail-Routing-Infrastruktur verursacht. Diese Änderung wurde in eine Messaging-Komponente umbenannt, die sowohl von unseren Staging- als auch von unseren Produktionsumgebungen verwendet wird. Da eine Produktionsregel von dieser freigegebenen Komponente abhing, führte die Umbenennung zu Lieferausfällen im Postfach **Send Us a Copy** und löste Nicht-Lieferungsberichte aus. Um dieses Problem zu beheben, hat unser Team die betroffene Konfiguration aktualisiert, um auf die richtige Komponente zu verweisen, und die Funktion **Send Us a Copy** wurde um 14:55 \(UTC\) wieder normal. Um diese Art von Problemen in Zukunft zu vermeiden, trennen wir E-Mail-Routing-Konfigurationen für unsere Staging- und Produktionsumgebungen. Wir stimmen auch bestehende Konfigurationen mit unseren aktuellen Infrastrukturmanagementstandards ab. Es ist kein Datenverlust infolge dieses Problems aufgetreten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 5. August 2026 um 19:29 UTCinvestigating

   We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.

2. 5. August 2026 um 21:24 UTCmonitoring

   Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.

3. 6. August 2026 um 21:56 UTCresolved

   Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.

1. 4. August 2026 um 19:19 UTCidentified

   Wir haben ein Problem festgestellt, das verhindert, dass Kontoeinstellungen in die SAT-Konsole geladen werden.

2. 4. August 2026 um 19:51 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 5. August 2026 um 12:17 UTCresolved

   Dieser Vorfall wurde behoben.

4. 28. September 2026 um 14:35 UTCpostmortem

   Am Dienstag, den 4. August 2026, von ca. 18:22 bis 19:43 \(UTC\), hatten einige Kunden Probleme beim Laden der **Kontoeinstellungen**-Seite in der KnowBe4-Konsole in den Regionen CA, DE, EU, Großbritannien und USA. Dieses Problem wurde durch eine Reihe von Anwendungsänderungen verursacht, die die Komplexität einer GraphQL-Anfrage erhöhten, die von der Benutzeroberfläche für Kontoeinstellungen verwendet wurde. Jede Änderung blieb unter dem Schwellenwert für die konfigurierte Komplexität der Plattform, wenn sie einzeln ausgewertet wurde, aber zusammengenommen überschritt die Anforderung diesen Schwellenwert und verhinderte das Laden der Seite. Engineering identifizierte die Komplexitätsschwelle als beitragenden Faktor und setzte eine Korrekturänderung ab etwa 19:14 \(UTC\) ein. Nachdem der Fix in den betroffenen Regionen verifiziert wurde, kehrte die KnowBe4-Konsole um ca. 19:43 \(UTC\) zur normalen Leistung zurück. Um dieses Problem in Zukunft zu verhindern, haben wir die Komplexitätsschwelle erhöht. Es ist kein Datenverlust infolge dieses Problems aufgetreten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. Juli 2026 um 20:00 UTCinvestigating

   Wir untersuchen ein Problem im Zusammenhang mit E-Mails, die von PhishRIP unerwartet unter Quarantäne gestellt werden

2. 28. Juli 2026 um 20:35 UTCmonitoring

   Für dieses Problem wurde ein Fix implementiert und PhishRIP-Abfragen stellen Nachrichten nicht mehr unerwartet unter Quarantäne. Wir untersuchen immer noch Anfragen, die möglicherweise betroffen waren

3. 29. Juli 2026 um 18:58 UTCresolved

   Dieser Vorfall wurde behoben.

4. 30. Juli 2026 um 16:38 UTCpostmortem

   ## **Zusammenfassung** Am 28. Juli 2026 führte ein Update des PhishRIP-Dienstes dazu, dass einige PhishRIP-Suchanfragen breiter übereinstimmten, als sie sollten. Gutartige E-Mails, die die konfigurierten Absenderkriterien nicht erfüllten, wurden in einigen Kundenkonten unter Quarantäne gestellt. Automatisierte Überwachungs- und Kundensupport-Tickets tauchten das Problem schnell auf. Engineering hat die Änderung innerhalb von etwa 25 Minuten nach der Erklärung des Vorfalls rückgängig gemacht und die unbeabsichtigte Quarantäne gestoppt. Engineering hat dann die falsch unter Quarantäne gestellten E-Mails in den Posteingang der Kunden manuell wiederhergestellt. ## **Wurzelursache** Am 28. Juli 2026 haben wir ein Wartungsupdate für den Abfragedienst hinter PhishRIP bereitgestellt. Dieses Update wurde entwickelt, um die Handhabung von ungültigen Absenderadressen zu verbessern, indem es dem System ermöglicht, nur den Domänenteil der Adresse zu durchsuchen. Die vorhandene Validierungslogik verwendete jedoch einen regulären Ausdruck, der ein "@" -Symbol im Absenderfeld erforderte. Wenn eine Abfrage eine Bare-Domain wie [example.com] (http://example.com) ohne Benutzername oder "@"-Symbol verwendete, kennzeichnete der Regex die Domain als ungültig. Dieser Konflikt zwischen der bestehenden Validierung und dem Domain-Such-Update führte dazu, dass das System die Absenderkriterien vollständig fallen ließ. Die Abfrage lief gegen Posteingänge, wobei nur die verbleibenden Parameter verwendet wurden, um E-Mails außerhalb des vorgesehenen Absenders abzugleichen und unter Quarantäne zu stellen. ## ** Timeline ** Alle Zeiten sind in UTC. | **Time** | **Event** | --- | --- | 19:36 | Unsere automatisierte Überwachung erkannte anomale Abfrageausführungsmuster und alarmierte unsere Ingenieure, die sofort mit der Untersuchung begannen. | | 19:51 | Das Problem wurde zu einem hochgradigen Produktionsvorfall eskaliert und ein Reaktionsteam wurde zusammengestellt. | | 19:52 | Unser Support-Team eskalierte die ersten Kundentickets, die unerwartete Quarantänen meldeten, und bestätigte die Überwachungswarnung. | | 19:54 | Die Ursache wurde auf eine kürzlich durchgeführte API-Bereitstellung zurückgeführt, und das Engineering begann, die Änderung rückgängig zu machen. | | 20:00 | Die Mitteilungen über Vorfälle wurden auf unserer Statusseite veröffentlicht, wobei PhishRIP als Degradiert markiert wurde. | | 20:16 | Der Einsatz wurde vollständig rückgängig gemacht. | | 20:35 | Produktionskontrollen bestätigten, dass Betreff- und Domänenabfragen wieder nur mit ihren beabsichtigten Zielen übereinstimmten und dass keine weiteren Nachrichten irrtümlich unter Quarantäne gestellt wurden. Unsere Statusseite wurde entsprechend aktualisiert. | | 20:39 | Engineering begann, die falsch unter Quarantäne gestellten E-Mails wiederherzustellen. | | 03:49 \(nächster Tag\) | Restaurierungen wurden für alle Kundenanfragen abgeschlossen, die über unser Support-Team protokolliert wurden. | ## **Abwehr und Sanierung** **Code zurück.** Wir haben abgewogen, aktive PhishRIP-Operationen mitten im Lauf zu stoppen, um den Code zurückzusetzen. Das Stoppen der Hintergrundaufgaben hätte legitime Sicherheitsworkflows für jeden Mandanten gestört, so dass das Zurücksetzen die bessere Option war. Der Code-Revert wurde in der Produktion innerhalb von etwa 40 Minuten Eskalation eingesetzt und verifiziert. **E-Mail-Wiederherstellung.** Um zu vermeiden, dass wirklich bösartige E-Mails wieder in Kundenumgebungen freigegeben werden, haben wir sie manuell und nicht in großen Mengen wiederhergestellt. Engineering verwendete interne Admin-Tools, um E-Mails in Batches wiederherzustellen, und arbeitete mit dem Support zusammen, um jede Konto-ID, Abfrage-ID zu überprüfen und zuerst die Kundengenehmigung zu erhalten. Alle gemeldeten Konten wurden über Nacht wiederhergestellt. ## **Vorbeugende Maßnahmen** * **Regressionsdeckung**: Wir fügen Unit- und Integrationstests für Domain-only-, Nicht-Standard- und Bare-String-Absenderanfragen hinzu, um diese Eingabefälle vor der Bereitstellung abzufangen. * **Query Leitplanken**: Wir fügen eine Überprüfung in der Abfrage-Engine hinzu, die die Ausführung von Abfragen blockiert, wenn ihre Kernfilterparameter während der Auswertung fallen gelassen werden. ## **Schlussfolgerung** Eine einzige Validierungsregel verursachte dies: ein Regex, der annahm, dass jedes Absenderfeld ein "@" enthielt. Wenn Abfragen eine reine Domäne verwendeten, ließ diese Annahme den Absenderfilter fallen und die Abfragen stimmten weit mehr E-Mails zu als beabsichtigt. Die Korrektur war einfach, sobald wir sie gefunden hatten, und der Rückschlag stoppte den Schaden innerhalb von etwa 25 Minuten nach der Erklärung des Vorfalls. Die Wiederherstellung unter Quarantäne gestellter E-Mails war ein schwierigerer Prozess: Wir konnten E-Mails nicht in großen Mengen wiederherstellen, ohne zu riskieren, dass wirklich bösartige E-Mails in Posteingänge zurückkehren. Unser Team entschied sich, sorgfältig vorzugehen und die ganze Nacht über Konto für Konto mit dem Support zu arbeiten. Zwei vorbeugende Maßnahmen hätten dies früher erkannt: ein Test, der nur domänenbasierte Absenderanfragen abdeckt, und eine Leitplanke, die sich weigert, eine Abfrage auszuführen, wenn der Absenderfilter entfernt wurde. Beide sind jetzt geplant. Das unmittelbare Problem ist behoben und alle gemeldeten Konten wurden wiederhergestellt. ## **Glossar** * **PhishRIP:** Eine PhishER-Funktion, mit der Administratoren nach passenden Phishing-E-Mails in jedem Benutzerposteingang einer Organisation suchen und diese unter Quarantäne stellen können. * **Regex \(regelmäßiger Ausdruck\):** Ein Muster, das in der Software verwendet wird, um Text zu durchsuchen und Eingaben zu validieren, z. B. um zu überprüfen, ob eine E-Mail-Adresse korrekt formatiert ist. * **Code zurück:** Sichern eines Software-Updates, um zur vorherigen stabilen Version zurückzukehren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. Juli 2026 um 13:18 UTCinvestigating

   Wir untersuchen, ob Benutzer keine Protect-Lizenzen auf store.knowbe4.com erwerben können. Wir werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

2. 17. Juli 2026 um 18:55 UTCmonitoring

   Wir haben einen Fix implementiert und überwachen die Ergebnisse, um sicherzustellen, dass keine weiteren Probleme auftreten.

3. 20. Juli 2026 um 18:24 UTCinvestigating

   Wir haben Berichte erhalten, dass Kunden keine Protect-Lizenzen auf store.knowbe4.com erwerben können. Wir untersuchen dieses Problem und werden diese Seite aktualisieren, wenn wir weitere Informationen haben.

4. 29. Juli 2026 um 18:40 UTCmonitoring

   Wir haben einen Fix für den Online-Shop implementiert und überwachen die Ergebnisse, um sicherzustellen, dass keine weiteren Probleme auftreten.

5. 17. August 2026 um 21:02 UTCmonitoring

   Wir überwachen weiterhin den implementierten Fix für den Online-Shop, um sicherzustellen, dass keine weiteren Probleme auftreten.

6. 11. September 2026 um 15:04 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.