Historique des pannes de Knowbe4

1. 4 septembre 2026 à 10:53 UTCinvestigating

   We have received reports of an issue with delivery of Email verification MFA for Workspace. We are investigating this issue and will update this page when we have more information.

2. 4 septembre 2026 à 14:24 UTCmonitoring

   We have received reports that the issue with delivery of Email verification MFA for Workspace has been mitigated by Microsoft, and we are monitoring the results.

3. 7 septembre 2026 à 08:25 UTCresolved

   This incident has been resolved.

1. 26 août 2026 à 16:19 UTCinvestigating

   We have identified an issue where users may experience delays in messages being processed, and our engineering team is looking into a fix.

2. 26 août 2026 à 16:46 UTCmonitoring

   Our engineering team has implemented a fix for the issue that causing message processing delays in PhishER, and we are monitoring the results.

3. 26 août 2026 à 19:51 UTCresolved

   Our engineering team has implemented a fix for the issue that causing message processing delays in PhishER.

1. 21 août 2026 à 08:52 UTCinvestigating

   We have received reports that the Gmail Phish Alert Button shows the error "[reportPhishAttempt()] An internal error has occurred. Please try again." when reporting phish. We are investigating this issue and will update this page when we have more information.

2. 21 août 2026 à 12:03 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 21 août 2026 à 13:08 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 21 août 2026 à 14:57 UTCresolved

   This incident has been resolved.

5. 26 août 2026 à 15:55 UTCpostmortem

   On Friday, August 21, 2026, from approximately 05:20 to 12:55 \(UTC\), some customers experienced intermittent failures when using the Gmail Phish Alert Button add-in to report suspicious emails, receiving the "An internal error has occurred" message instead of a successful report confirmation. The issue affected customers across all regions, with the highest error volumes concentrated in the EU-West and US-East service regions. This issue was caused by a disruption in a caching service on Google's Apps Script platform, which the add-in relies on to store per-user session configuration. The service began intermittently returning empty results on read while still accepting new writes, causing affected report submissions to fail. KnowBe4 engaged Google directly and filed a formal bug report between approximately 12:19 and 12:39 \(UTC\). Error volume declined sharply shortly after as the vendor-side condition cleared, and the Gmail Phish Alert Button returned to normal performance by approximately 12:55 \(UTC\). To prevent this type of issue in the future, we are continuing to work with Google to track the resolution of the underlying caching defect. No data loss occurred as a result of this issue.

1. 18 août 2026 à 14:29 UTCinvestigating

   We are investigating an issue causing a Non-Delivery Report (NDR) to be returned when a message is reported via the Phish Alert Button and "Send Us a Copy" is enabled in Account Settings

2. 18 août 2026 à 15:26 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 18 août 2026 à 20:14 UTCresolved

   This incident has been resolved.

1. 5 août 2026 à 19:29 UTCinvestigating

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

2. 5 août 2026 à 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 août 2026 à 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 août 2026 à 19:19 UTCidentified

   We have identified an issue preventing account settings from loading in the SAT console.

2. 4 août 2026 à 19:51 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 5 août 2026 à 12:17 UTCresolved

   This incident has been resolved.

1. 28 juillet 2026 à 20:00 UTCinvestigating

   Nous enquêtons sur un problème lié aux courriels mis en quarantaine par PhishRIP de façon inattendue

2. 28 juillet 2026 à 20:35 UTCmonitoring

   Une correction a été implémentée pour ce problème et les requêtes PhishRIP ne sont plus en attente de messages. Nous enquêtons encore sur des questions qui pourraient avoir été touchées

3. 29 juillet 2026 à 18:58 UTCresolved

   Cet incident a été résolu.

4. 30 juillet 2026 à 16:38 UTCpostmortem

   Résumé Le 28 juillet 2026, une mise à jour du service PhishRIP a amené certaines requêtes de recherche PhishRIP à correspondre plus largement qu'elles ne l'auraient dû. Des courriels bénins qui ne répondaient pas aux critères d'expéditeur configurés ont été mis en quarantaine sur certains comptes clients. Des tickets automatisés de surveillance et d'assistance à la clientèle ont rapidement fait surface. Le génie a repris le changement dans les environ 25 minutes suivant la déclaration de l'incident et a arrêté la quarantaine non intentionnelle. Ingénierie puis manuellement restauré les courriels mal mis en quarantaine aux boîtes de réception des clients. La cause de la mort Le 28 juillet 2026, nous avons déployé une mise à jour de maintenance au service de requête derrière PhishRIP. Cette mise à jour a été conçue pour améliorer le traitement des adresses d'expéditeurs invalides en permettant au système de revenir à la recherche seulement la partie du domaine de l'adresse. Cependant, la logique de validation existante utilisait une expression régulière qui exigeait un symbole "@" dans le champ de l'expéditeur. Lorsqu'une requête utilise un domaine nu, tel que [example.com](http://example.com) sans nom d'utilisateur ou symbole "@", le regex indique que le domaine est invalide. Ce conflit entre la validation existante et la mise à jour de la recherche de domaine a conduit le système à supprimer complètement les critères d'expéditeur. La requête s'est déroulée contre les boîtes de réception en utilisant seulement les paramètres restants, les courriels de correspondance et de quarantaine bien en dehors de l'expéditeur prévu. **Échéancier** Toutes les heures sont en UTC. **Heure** - Oui. Notre surveillance automatisée a détecté des modèles d'exécution de requêtes anormales et a alerté nos ingénieurs, qui ont immédiatement commencé à enquêter. Autres Le problème a été aggravé par un incident de production de haute gravité, et une équipe d'intervention a été constituée. Autres Notre équipe de support a intensifié les premiers tickets clients qui ont signalé des quarantaines inattendues, corroborant l'alerte de surveillance. La cause fondamentale a été attribuée à un déploiement d'API de requêtes récentes, et l'ingénierie a commencé à revenir au changement. Les communications d'incident ont été postées sur notre page de statut, avec PhishRIP marqué comme Dégradé. 20:16 Le déploiement a été entièrement repris. Les vérifications de production ont confirmé que les questions de sujet et de domaine correspondaient de nouveau uniquement à leurs objectifs et qu'aucun autre message n'était mis en quarantaine par erreur. Notre page de statut a été mise à jour en conséquence. Autres L'ingénierie a commencé à restaurer les courriels mal mis en quarantaine. 03:49 \(prochaine journée\)= Les restaurations ont été effectuées pour tous les ensembles de requêtes client enregistrés par notre équipe de support. **Atténuation et assainissement** **Code retourné.** Nous avons pesé l'arrêt des opérations PhishRIP actives au milieu de la course contre le retour du code. Réduire les tâches de base aurait perturbé les flux de travail légitimes de sécurité pour chaque locataire, de sorte que le retour était la meilleure option. Le retour au code a été déployé et vérifié dans la production dans les 40 minutes suivant l'escalade. **Restauration par courriel.** Pour éviter de relâcher des e-mails vraiment malveillants dans les environnements clients, nous les avons restaurés manuellement plutôt que en vrac. L'ingénierie a utilisé des outils d'administration interne pour restaurer les e-mails en lots, et a travaillé avec Support pour vérifier chaque identifiant de compte, l'identifiant de requête et recevoir l'approbation du client d'abord. Tous les comptes déclarés ont été rétablis du jour au lendemain. ** Mesures préventives** * **Couverture de la régression** : Nous ajoutons des tests d'unité et d'intégration pour les requêtes d'expéditeurs de domaine, non standard et à chaîne nue pour attraper ces cas d'entrée avant le déploiement. * **Gardiers de secours**: Nous ajoutons une vérification dans le moteur de requête qui bloque les requêtes en cours d'exécution si leurs paramètres de filtrage de cœur sont supprimés pendant l'évaluation. **Conclusion** Une seule règle de validation en a résulté : un regex qui a supposé que chaque champ expéditeur contenait un `@`. Lorsque les requêtes utilisaient un domaine nu, cette hypothèse laissait tomber le filtre de l'expéditeur et les requêtes correspondaient beaucoup plus au courrier que prévu. La correction a été simple une fois que nous l'avons trouvé, et le retour a arrêté les dommages dans les 25 minutes suivant la déclaration de l'incident. Restaurer le courrier mis en quarantaine a été un processus plus difficile : nous ne pouvions pas restaurer les courriels en vrac sans risquer que des courriels véritablement malveillants retournent dans des boîtes de réception. Notre équipe a choisi de procéder avec soin, compte de travail par compte avec Support toute la nuit. Deux mesures préventives auraient été prises plus tôt : un test couvrant uniquement les requêtes d'expéditeur de domaine, et un garde-corps qui refuse d'exécuter une requête lorsque son filtre d'expéditeur a été dépouillé. Les deux sont maintenant prévus. Le problème immédiat est résolu et tous les comptes rendus ont été rétablis. ## **Glossaire** * **PhishRIP:** Une fonctionnalité PhishER qui permet aux administrateurs de rechercher et de mettre en quarantaine des courriels d'hameçonnage correspondants dans chaque boîte de réception utilisateur dans une organisation. * **Regex \(expression régulière):** Un modèle utilisé dans le logiciel pour rechercher du texte et valider l'entrée, comme vérifier qu'une adresse e-mail est formatée correctement. * ** Code retourné :** Sauvegarder une mise à jour logicielle pour revenir à la version stable précédente.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 juillet 2026 à 13:18 UTCinvestigating

   Nous enquêtons sur les utilisateurs ne pouvant pas acheter les licences Protect sur store.knowbe4.com. Nous mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 17 juillet 2026 à 18:55 UTCmonitoring

   Nous avons mis en place un correctif et nous suivons les résultats pour nous assurer qu'aucun autre problème ne se pose.

3. 20 juillet 2026 à 18:24 UTCinvestigating

   Nous avons reçu des rapports selon lesquels les clients ne sont pas en mesure d'acheter des licences Protect sur store.knowbe4.com. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

4. 29 juillet 2026 à 18:40 UTCmonitoring

   Nous avons implémenté un correctif pour la boutique en ligne et nous suivons les résultats pour nous assurer qu'il n'y a pas d'autres problèmes.

5. 17 août 2026 à 21:02 UTCmonitoring

   We are continuing to monitor the implemented fix for the online store, to ensure that no further issues occur.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 19:48 UTCinvestigating

   Nous avons identifié un problème où les utilisateurs peuvent recevoir une redirection lors de la connexion à Defend, et notre équipe d'ingénierie examine une solution.

2. 16 juillet 2026 à 20:09 UTCidentified

   Une correction a été identifiée, et nous surveillerons les résultats au fur et à mesure qu'ils se dérouleront.

3. 16 juillet 2026 à 21:20 UTCresolved

   Cet incident a été résolu.

4. 20 août 2026 à 21:32 UTCpostmortem

   On Thursday, July 16, 2026, from approximately 19:57 to 21:12 \(UTC\), some customers experienced difficulty logging in to the Defend console, seeing a **Find Out More** screen instead of console access. This issue was caused by a synchronization issue between Salesforce and our internal licensing systems, which incorrectly set some customer license counts to zero. As a result, affected customers were unable to log in. To resolve this issue, our team applied a temporary license override to restore access for affected customers while correcting the underlying licensing records in Salesforce. Once corrected, the systems automatically synchronized the accurate values, and the Defend console access returned to normal performance by approximately 21:12 \(UTC\). To prevent this type of issue in the future, we are implementing improvements to the Salesforce synchronization process to ensure accurate license counts. No data loss occurred as a result of this issue.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 juillet 2026 à 16:51 UTCinvestigating

   Nous enquêtons sur les utilisateurs ne pouvant pas acheter les licences Protect sur store.knowbe4.com. Nous mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 15 juillet 2026 à 16:54 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 16 juillet 2026 à 01:23 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 16 juillet 2026 à 14:04 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 juillet 2026 à 21:01 UTCresolved

   Un problème de service de flag en amont a dégradé le routage du modèle en raison de l'inférence de collaboration, ce qui a amené les évaluations PhishML à renvoyer les erreurs 0/0/0 par défaut. Le tiers a déployé une correction, et une mise à jour de code a été déployée pour la production en ajoutant un routage statique de repli. Tous les services se sont rétablis et fonctionnent normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 juillet 2026 à 14:40 UTCinvestigating

   We have received reports that users are experiencing issues when logging into the US instance. We are investigating this issue and will update this page when we have more information.

2. 1 juillet 2026 à 16:02 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 1 juillet 2026 à 18:01 UTCresolved

   This incident has been resolved.

4. 8 juillet 2026 à 18:52 UTCpostmortem

   ## **Executive Summary** On July 1, 2026, the KnowBe4 Security Awareness Training \(KSAT\) platform experienced a period of degraded performance resulting in intermittent login errors and high latency for users on our United States \(US\) instance. The issue was initiated following a routine platform deployment that introduced an unoptimized database query. This query placed an excessive operational load on our primary database reader cluster, causing database sessions to saturate and subsequent login requests to queue up. Engineering teams promptly identified the degradation, reverted the deployment, and systematically cleared the backlogged database sessions to restore optimal performance. The issue did not affect data integrity or security, and service was fully stabilized. ## **Technical Root Cause** The root cause was determined to be a newly introduced query within a standard application update. Upon deployment, this specific query pattern bypassed optimal indexing strategies, resulting in full table scans and highly extended execution times on the database reader infrastructure. As a high volume of authentication and application requests arrived concurrently, the database reader quickly exhausted its available connection pool due to these long-running, unmitigated database sessions. This resource starvation immediately manifested as severe application latency and intermittent timeouts during the user authentication process. ## **Timeline of Events** The incident began in the mid-morning hours and progressed through identification, remediation, and verification stages over a period of approximately 152 minutes. An internal high-severity incident response group was established immediately following automated monitoring alerts indicating that health checks targeting our application programming interface \(API\) routing layer were failing from regional cloud monitoring nodes. This behavior was confirmed by concurrent engineering analysis of user HTTP Archive files, which demonstrated severe latency spikes specifically isolated to the authentication endpoints. Within three minutes of establishing the response team, cross-referencing recent system changes pointed to a recent application deployment as the primary catalyst. Engineers immediately initiated the rollback process, drafting and approving a revert modification to extract the problematic code from the deployment pipeline. The deployment of the reverted codebase to the US production cluster commenced shortly thereafter. While the deployment processed over the subsequent twenty-five minutes, technical personnel prepared direct database interventions to clear the residual system strain. Once the stable code version was completely active across the fleet, engineers began systematically terminating the lingering, long-running database sessions that had been spawned by the unoptimized query. To ensure a pristine state, the database reader infrastructure was cycled twice. Following these administrative infrastructure restarts, operational telemetry showed the database reader load dropping significantly to a healthy baseline of approximately thirty-six percent. System performance normalized, and administrative logging verified that authentication requests were processing within standard latency thresholds. After monitoring the environment to confirm sustained stability, engineers officially marked the incident as mitigated, later shifting the status to fully resolved following an extended window of zero performance spikes and complete passes on all automated sanity test suites. ## **Mitigation** To alleviate the immediate infrastructure distress and restore user access, the engineering team executed a multi-phased mitigation strategy: * **Codebase Rollback:** The changes introduced in the recent deployment were immediately isolated, reverted, and redeployed to production to prevent any further generation of the unoptimized query. * **Database Session Termination:** Internal engineering tools were utilized to explicitly terminate active, long-running database queries that were blocking the connection pools. * **Infrastructure Cycling:** The database reader instances were restarted twice in succession to flush out stale memory allocations and guarantee that all orphaned database sessions were permanently cleared. ## **Preventative Measures** To prevent a recurrence of this specific issue and mitigate the impact of similar query-based database bottlenecks in the future, KnowBe4 is implementing the following actions: * **Enhanced Query Linting and Analysis:** Integrate automated query execution plan analysis into our continuous integration and continuous deployment pipelines to flag unindexed or high-cost queries before they reach production environments. * **Database Connection Pooling Guardrails:** Adjust database timeouts and implement aggressive circuit-breaker thresholds for user authentication paths to prevent single, long-running query patterns from exhausting the entire connection pool. * **Load Shedding Policies:** Implement strict application-level timeouts on read-heavy database calls to ensure they fail gracefully rather than degrading the overall availability of the core login workflows. ## **Conclusion** We sincerely apologize for the inconvenience and friction this performance degradation caused our customers and partners. KnowBe4 is dedicated to maintaining high availability and reliability across our product suites. By refining our pre-deployment automated query validation and bolstering our database connection resiliency, we are actively working to ensure the continuous, seamless operation of the KSAT platform. ## **Glossary of Technical Terms** * **API \(Application Programming Interface\):** A set of protocols that allows different software applications to communicate with one another. In this context, it routes authentication requests from the user interface to the backend servers. * **Database Reader:** A dedicated database instance or cluster responsible for handling read-only queries \(such as fetching user profiles or validating login configurations\), separating this traffic from write operations to optimize performance. * **HAR \(HTTP Archive\) File:** A JSON-formatted log file that records a web browser's interaction with a website, used by engineers to diagnose performance and network latency issues. * **Latency:** The time delay or duration it takes for a data packet or request to travel from its source to its destination and return a response. * **Sanity Suite:** A collection of automated tests executed against a deployment environment to quickly verify that the core functionality of an application is working correctly.

1. 30 juin 2026 à 16:14 UTCinvestigating

   We have received reports that emails sent to Defend are experiencing delays being delivered to inboxes using SMTP. We are investigating this issue and will update this page when we have more information.

2. 30 juin 2026 à 19:46 UTCresolved

   This incident has been resolved.

3. 3 juillet 2026 à 15:23 UTCpostmortem

   #### Summary On June 30, 2026, customers using the Defend US service experienced delays in email processing. The incident began at approximately 14:00 UTC and was fully resolved by 19:45 UTC. ‌ #### What Happened A scheduled maintenance operation began in the early morning of June 30. As this operation progressed, it placed an unexpectedly high load on our infrastructure, which caused email processing to slow down across our US service. ‌ Our team identified the issue and declared an incident at 16:00 UTC. Steps were taken to reduce the load and restore normal processing speeds, including pausing non-essential background activity and engaging our infrastructure provider for additional support. ‌ By 17:45 UTC, email delivery delays had been fully resolved. Email analysis continued to recover and was back to normal by 19:45 UTC. ‌ #### Customer Impact Email delivery \(SMTP customers\): Emails were delayed in transit by up to 30 minutes between approximately 14:00 UTC and 17:45 UTC. All emails were delivered; no messages were lost. ‌ Email analysis \(Microsoft 365 / Graph API customers\): Email analysis was delayed by an average of 30 minutes before emails were analysed, between approximately 14:00 UTC and 19:45 UTC. Email delivery to end users was not affected. ‌ #### What We Are Doing We have rescheduled the maintenance operation that triggered this incident to run during an overnight, low-traffic window, giving it sufficient time to complete without affecting the live service. ‌ We are also investing in infrastructure improvements to better isolate maintenance operations from customer-facing workloads, so that future maintenance cannot affect email processing in this way.

1. 30 juin 2026 à 14:18 UTCinvestigating

   Nous avons identifié un problème où les évaluations PhishML provoquent l'application de l'étiquette « PML:BYPASSED ».

2. 30 juin 2026 à 15:42 UTCmonitoring

   Nous avons mis en place un correctif pour PhishER et nous suivons les résultats pour nous assurer qu'il n'y a pas d'autres problèmes. Les messages touchés peuvent être rejoués à travers toutes les règles et actions. Veuillez noter que cela pourrait entraîner l'envoi de réponses en double si une action a été menée avec succès pendant cet incident. Si vous avez d'autres questions ou préoccupations, veuillez contacter notre équipe de soutien directement : https://support.knowbe4.com/hc/en-us/requests/new L'article de base de connaissances suivant contient des instructions sur la façon de rejouer les messages : https://support.wnowbe4.com/hc/en-us/articles/13169303385619-PhishER-Inbox-Guide#h 01HCNEBF8CJQ98GE9PGM7HGDZ0

3. 30 juin 2026 à 19:11 UTCresolved

   Cet incident a été résolu.

4. 22 juillet 2026 à 13:20 UTCpostmortem

   Le mardi 30 juin 2026, de 07:40 à 19:15 \(UTC\), les clients ont connu des résultats incorrects de PhishER PhishML score. Les courriels touchés ont reçu une étiquette PML:BYPASSED au lieu d'une classification PhishML légitime, et des notes de confiance étaient manquantes dans les messages touchés. Les règles et actions qui dépendent des résultats PhishML n'ont pas non plus été activées. Cette question a été causée par un refacteur de code introduit environ deux semaines plus tôt. Ce refacteur a introduit une mise à jour erronée qui a omis les pilotes essentiels requis pour la notation PhishML pour courir. Toutefois, le problème est resté inactif jusqu'à ce qu'une autre mise à jour déclenche un nouveau déploiement du modèle PhishML, ce qui a fait émerger le problème de notation. Pour résoudre ce problème, notre équipe est revenue au dernier déploiement stable et a renforcé sa capacité de traiter l'arriéré d'évaluations par courriel. Le score PhishML de PhishER est revenu à la performance normale de 19:15 \(UTC\). Afin d'éviter ce genre de problème à l'avenir, nous avons amélioré les contrôles de santé en introduisant un nouveau paramètre pour l'essai de la fumée de nouveaux modèles avant le déploiement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juin 2026 à 15:48 UTCinvestigating

   We have identified an issue where users may receive a 500 error upon logging into KCM GRC, and our engineering team is looking into a fix.

2. 24 juin 2026 à 22:06 UTCmonitoring

   We have identified an issue where users may receive a 500 error upon logging into KCM GRC. A fix has been implemented, and we will continue to monitor this issue.

3. 25 juin 2026 à 13:10 UTCresolved

   We have identified an issue where users may receive a 500 error upon logging into KCM GRC. A fix has been implemented, and users should be able to login without error.

4. 4 août 2026 à 14:50 UTCpostmortem

   From Tuesday, June 23, 2026, at approximately 10:03 \(UTC\) to Thursday, June 25, 2026, at approximately 11:54 \(UTC\), some US and EU customers experienced intermittent 502 errors when logging in to KCM GRC. This issue was caused by network traffic attempting to connect to invalid multilevel subdomains, which overwhelmed the cache serving KCM GRC and resulted in login errors. Our team initially updated the configuration of our content delivery network, which temporarily resolved the errors, but they returned later that day. After further investigation, we identified the caching issue as the root cause and deployed an infrastructure-level fix to prevent multi-level subdomain traffic from affecting the cache. KCM GRC returned to normal performance by 11:54 \(UTC\) on June 25, 2026. To prevent this type of issue in the future, we are evaluating additional protections to guard against similar traffic that could affect the cache. No data loss occurred as a result of this issue.

1. 18 juin 2026 à 21:14 UTCinvestigating

   We have received reports of the Phishing test reports tab currently being unavailable. We are investigating this issue and will update this page when we have more information.

2. 18 juin 2026 à 21:16 UTCinvestigating

   We are continuing to investigate this issue.

3. 18 juin 2026 à 22:42 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 19 juin 2026 à 14:01 UTCresolved

   This incident has been resolved.

5. 7 juillet 2026 à 19:45 UTCpostmortem

   From Tuesday, June 16, 2026, at approximately 17:34 \(UTC\), to Thursday, June 18, 2026, at approximately 22:41 \(UTC\), some customers experienced intermittent unavailability of the **Phishing Security Test Reports** page in the KnowBe4 console. This issue was caused by a code change that introduced a conflict between two methods for processing phishing campaign data. As a result, phishing campaigns still using legacy phishing categories were unable to load the **Phishing Security Test Reports** page. To resolve this issue, we updated the code to process campaigns correctly under both classification systems, and the **Phishing Security Test Reports** page returned to normal performance by June 18, 2026, at 22:41 \(UTC\). No data loss occurred as a result of this issue.

1. 18 juin 2026 à 15:13 UTCinvestigating

   We have received reports that the Human Risk Managment widget is showing no results in the KnowBe4 Security Center. We are investigating this issue and will update this page when we have more information.

2. 18 juin 2026 à 15:43 UTCmonitoring

   We’ve implemented a fix for the Human Risk Management widget and we’re monitoring the results to make sure no further issues occur.

3. 18 juin 2026 à 19:12 UTCresolved

   This incident has been resolved.

4. 8 septembre 2026 à 15:44 UTCpostmortem

   From Wednesday, June 17, 2026, at approximately 19:00 \(UTC\), to Thursday, June 18, 2026, at approximately 18:20 \(UTC\), some customers were unable to view results in the KnowBe4 Security Center’s Human Risk Management widget. ‌ This issue was caused by a recent infrastructure migration that left an internal service connection pointing to an outdated endpoint. Though the underlying data processing was unaffected, the Human Risk Management widget could not retrieve data or display results. To resolve this issue, our team updated and reapplied the connection configuration, and the KnowBe4 Security Center returned to normal performance by approximately 18:20 \(UTC\) on June 18, 2026. To prevent this type of issue in the future, we are improving our migration process to ensure that all endpoints are valid after a migration. We are also strengthening known-good rollback procedures in cases where a migration cannot be completed as planned. No data loss occurred as a result of this issue.

1. 16 juin 2026 à 22:23 UTCinvestigating

   We've identified an issue that has resulted in inconsistent reporting, and our engineering team is looking into a fix.

2. 17 juin 2026 à 12:48 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 17 juin 2026 à 20:19 UTCresolved

   This incident has been resolved.

4. 21 août 2026 à 18:00 UTCpostmortem

   From Tuesday, June 16, 2026, at approximately 22:23 \(UTC\), to Wednesday, June 17, 2026, at approximately 20:19 \(UTC\), some customers experienced inaccurate user counts in KSAT reporting. Downstream features that rely on this data were also affected, including AIDA Orchestration, Risk Score, and ModStore recommendations. This issue was caused by an incomplete rebuild of the users' data table. A data storage policy removed historical data earlier than intended, so when a full table rebuild ran, some older data was unavailable, causing user counts to drop. To resolve this issue, our team performed a full data migration sync on the users' table and retriggered the dependent data pipelines to update downstream systems. We then tested and confirmed that user counts were returning correct results, and the KSAT console returned to normal performance by June 17, 2026, at 20:19 \(UTC\). To prevent this type of issue in the future, we are correcting the underlying data storage policy to ensure complete historical data is retained for the full rebuild process. No data loss occurred as a result of this issue.

1. 15 juin 2026 à 16:56 UTCresolved

   This incident has been resolved.

2. 20 août 2026 à 19:41 UTCpostmortem

   On Monday, June 15, 2026, from approximately 15:30 to 16:34 \(UTC\), some customers experienced processing delays with phishing and training campaigns in the KnowBe4 console. This issue was caused by an update that introduced an incompatible software version. This software prevented our background processing service from completing queued tasks. As a result, training enrollments, notification sending, and SmartGgroup enrollments were delayed. To resolve this issue, our team deployed a fix that reverted the affected dependency and restored normal job processing. Once the fix was deployed, the affected queues cleared, and the KnowBe4 console returned to normal performance by 16:34 \(UTC\). To prevent this issue in the future, we have implemented additional testing layers for similar deployments. No data loss occurred as a result of this issue.

1. 3 juin 2026 à 15:07 UTCinvestigating

   Nous avons reçu des rapports d'erreurs de 500 lors de la navigation vers des profils d'utilisateurs. Nous enquêtons sur cette question et mettrons à jour cette page lorsque nous aurons plus d'informations.

2. 3 juin 2026 à 16:16 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 3 juin 2026 à 18:14 UTCresolved

   Cet incident a été résolu.

4. 15 juillet 2026 à 15:23 UTCpostmortem

   Le mercredi 3 juin 2026, de 14:49 à 16:09 \(UTC\), les clients ont éprouvé des erreurs lors de l'accès à la page **Détails de l'utilisateur** dans la console KSAT. Ce problème a été causé par une mise à jour qui a introduit des champs manquants, ce qui a empêché la page **Détails de l'utilisateur** de charger. Pour résoudre ce problème, notre équipe a réactualisé la console pour restaurer les champs manquants, et la console KSAT est revenue à des performances normales d'environ 16:09 \(UTC\). Afin d'éviter des problèmes semblables à l'avenir, d'autres tests automatisés ont été ajoutés. Aucune perte de données n'a été causée par ce problème.

Traduit automatiquement depuis la mise à jour officielle de l'incident.