Ιστορικό διακοπών του Knowbe4

1. 5 Αυγούστου 2026 στις 7:29 μ.μ. UTCinvestigating

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

2. 5 Αυγούστου 2026 στις 9: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 Αυγούστου 2026 στις 9: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 Αυγούστου 2026 στις 7:19 μ.μ. UTCidentified

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

2. 4 Αυγούστου 2026 στις 7:51 μ.μ. UTCmonitoring

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

3. 5 Αυγούστου 2026 στις 12:17 μ.μ. UTCresolved

   This incident has been resolved.

1. 28 Ιουλίου 2026 στις 8:00 μ.μ. UTCinvestigating

   Ερευνούμε ένα θέμα που σχετίζεται με μηνύματα ηλεκτρονικού ταχυδρομείου που βρίσκονται σε καραντίνα από το PhishRIP απροσδόκητα

2. 28 Ιουλίου 2026 στις 8:35 μ.μ. UTCmonitoring

   Μια διόρθωση έχει εφαρμοστεί για αυτό το θέμα και τα ερωτήματα PhishRIP δεν είναι πλέον εγγύηση μηνύματα απροσδόκητα. Ακόμα ερευνούμε ερωτήματα που μπορεί να έχουν επηρεαστεί

3. 29 Ιουλίου 2026 στις 6:58 μ.μ. UTCresolved

   Το περιστατικό λύθηκε.

4. 30 Ιουλίου 2026 στις 4:38 μ.μ. UTCpostmortem

   \"Περίληψη\" Στις 28 Ιουλίου 2026, μια ενημέρωση στην υπηρεσία PhishRIP προκάλεσε κάποια ερωτήματα αναζήτησης PhishRIP να ταιριάζουν ευρύτερα από ό, τι θα έπρεπε. Καλοήθη μηνύματα που δεν πληρούσαν τα ρυθμισμένα κριτήρια αποστολής μπήκαν σε καραντίνα σε κάποιους λογαριασμούς πελατών. Η αυτοματοποιημένη παρακολούθηση και η υποστήριξη πελατών ανέκυψαν γρήγορα στο πρόβλημα. Το μηχανοστάσιο επανέφερε την αλλαγή μέσα σε περίπου 25 λεπτά από την κήρυξη του συμβάντος και σταμάτησε την ακούσια καραντίνα. Στη συνέχεια, η μηχανική επανέφερε χειροκίνητα τα λανθασμένα ηλεκτρονικά μηνύματα σε καραντίνα στα εισερχόμενα των πελατών. . . . . . . Στις 28 Ιουλίου 2026, αναπτύξαμε μια ενημέρωση συντήρησης στην υπηρεσία ερωτημάτων πίσω από το PhishRIP. Αυτή η ενημέρωση σχεδιάστηκε για να βελτιώσει τον χειρισμό των μη έγκυρων διευθύνσεων αποστολέα επιτρέποντας στο σύστημα να υποχωρήσει στην αναζήτηση μόνο του τμήματος τομέα της διεύθυνσης. Ωστόσο, η υπάρχουσα λογική επικύρωσης χρησιμοποίησε μια κανονική έκφραση που απαιτούσε ένα σύμβολο "@" στο πεδίο αποστολέα. Όταν ένα ερώτημα χρησιμοποίησε έναν γυμνό τομέα, όπως [παράδειγμα.com](http://example.com) χωρίς όνομα χρήστη ή "@" σύμβολο, ο regex δήλωνε τον τομέα ως άκυρο. Αυτή η σύγκρουση μεταξύ της υπάρχουσας επικύρωσης και της επικαιροποίησης domain-search προκάλεσε την πλήρη πτώση των κριτηρίων αποστολέα. Το ερώτημα έτρεξε ενάντια inboxes χρησιμοποιώντας μόνο τις υπόλοιπες παραμέτρους του, ταίριασμα και quarantining μηνύματα ηλεκτρονικού ταχυδρομείου πολύ έξω από την προβλεπόμενη αποστολέα. Χρονογραμμή ** Όλες οι ώρες είναι σε UTC. 19:36 19:51 Το θέμα κλιμακώθηκε σε ένα περιστατικό παραγωγής υψηλής βαρύτητας, και μια ομάδα ανταπόκρισης συναρμολογήθηκε. 19:52 19:54 20:00 20:35 Η σελίδα κατάστασης μας ενημερώθηκε ανάλογα. 20:39 Μηχανική άρχισε να αποκαθιστά τα λανθασμένα σε καραντίνα μηνύματα ηλεκτρονικού ταχυδρομείου. Απαγόρευση και αποκατάσταση ** ** Κωδικός επαναφοράς ** Ζυγίσαμε την αναχαίτιση των ενεργών επιχειρήσεων PhishRIP κατά την επιστροφή του κώδικα. Η διακοπή των εργασιών του ιστορικού θα είχε διαταράξει τις νόμιμες ροές εργασίας ασφαλείας για κάθε ενοικιαστή, έτσι η επαναφορά ήταν η καλύτερη επιλογή. Ο κώδικας επαναφοράς αναπτύχθηκε και επαληθεύτηκε στην παραγωγή μέσα σε περίπου 40 λεπτά από την κλιμάκωση. ** Αποκατάσταση email. ** Για να αποφύγουμε την κυκλοφορία πραγματικά κακόβουλων μηνυμάτων ηλεκτρονικού ταχυδρομείου πίσω σε περιβάλλοντα πελατών, τα αποκαταστήσαμε χειροκίνητα και όχι χύμα. Μηχανική χρησιμοποίησε εσωτερικά εργαλεία admin για την αποκατάσταση των μηνυμάτων ηλεκτρονικού ταχυδρομείου σε παρτίδες, και εργάστηκε με την Υποστήριξη για να επαληθεύσει κάθε ID λογαριασμού, ερώτημα ID, και να λάβει την έγκριση του πελάτη πρώτα. Όλοι οι αναφερόμενοι λογαριασμοί αποκαταστάθηκαν σε μια νύχτα. ** Προληπτικά μέτρα ** * ** Κάλυψη οπισθοδρόμησης **: Προσθέτουμε μονάδες και δοκιμές ενσωμάτωσης μόνο για domain-one, non-standard, και γυμνόχορδη ερωτήματα αποστολέα για να πιάσει αυτές τις περιπτώσεις εισόδου πριν από την ανάπτυξη. * * * * Query Guardrails * *: Προσθέτουμε έναν έλεγχο στη μηχανή ερωτημάτων που εμποδίζει τα ερωτήματα από το να τρέχουν εάν οι παράμετροι φιλτραρίσματος πυρήνα τους πέφτουν κατά τη διάρκεια της αξιολόγησης. **Συμπέρασμα ** Ένας ενιαίος κανόνας επικύρωσης προκάλεσε αυτό: ένα regex που υπέθεσε κάθε πεδίο αποστολέα περιείχε ένα `@`. Όταν τα ερωτήματα χρησιμοποίησαν ένα γυμνό πεδίο, η υπόθεση αυτή έριξε το φίλτρο αποστολέα και τα ερωτήματα αντιστοιχούσαν πολύ περισσότερο ταχυδρομείο από ό, τι είχε προβλεφθεί. Η διόρθωση ήταν ξεκάθαρη μόλις την βρήκαμε, και η επαναφορά σταμάτησε τη ζημιά μέσα σε περίπου 25 λεπτά από την κήρυξη του συμβάντος. Η αποκατάσταση της καραντίνας αλληλογραφίας ήταν μια πιο δύσκολη διαδικασία: δεν μπορούσαμε να αποκαταστήσουμε τα μηνύματα ηλεκτρονικού ταχυδρομείου χύμα χωρίς να ρισκάρουμε πραγματικά κακόβουλα μηνύματα ηλεκτρονικού ταχυδρομείου να επιστρέψουν στα εισερχόμενα. Η ομάδα μας επέλεξε να προχωρήσει προσεκτικά, δουλεύοντας με λογαριασμό στην Υποστήριξη όλη τη νύχτα. Δύο προληπτικά μέτρα θα έπιαναν αυτό νωρίτερα: μια δοκιμή που καλύπτει ερωτήματα αποστολέα μόνο τομέα, και ένα guardrail που αρνείται να τρέξει ένα ερώτημα όταν το φίλτρο αποστολέα του έχει απογυμνωθεί. Και τα δύο είναι τώρα προγραμματισμένα. Το άμεσο ζήτημα λύθηκε και όλοι οι λογαριασμοί αποκαταστάθηκαν. . . . . . . * **PhishRIP: ** Ένα χαρακτηριστικό PhishER που επιτρέπει στους διαχειριστές αναζήτηση και καραντίνα που ταιριάζουν με τα μηνύματα phishing σε κάθε χρήστη inbox σε έναν οργανισμό. * **Regex \ (κανονική έκφραση\): ** Ένα μοτίβο που χρησιμοποιείται στο λογισμικό για την αναζήτηση κειμένου και την επικύρωση εισόδου, όπως ο έλεγχος ότι μια διεύθυνση ηλεκτρονικού ταχυδρομείου διαμορφώνεται σωστά. * ** Κωδικός επαναφοράς: ** Πίσω από μια ενημέρωση λογισμικού για να επιστρέψει στην προηγούμενη σταθερή έκδοση.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 17 Ιουλίου 2026 στις 1:18 μ.μ. UTCinvestigating

   Ερευνούμε χρήστες που δεν είναι σε θέση να αγοράσουν Protect άδειες στο κατάστημα.nowbe4.com. Θα ενημερώσουμε αυτή τη σελίδα όταν έχουμε περισσότερες πληροφορίες.

2. 17 Ιουλίου 2026 στις 6:55 μ.μ. UTCmonitoring

   Έχουμε εφαρμόσει μια λύση και παρακολουθούμε τα αποτελέσματα για να διασφαλίσουμε ότι δεν θα προκύψουν περαιτέρω ζητήματα.

3. 20 Ιουλίου 2026 στις 6:24 μ.μ. UTCinvestigating

   Έχουμε λάβει αναφορές ότι οι πελάτες δεν είναι σε θέση να αγοράσουν Protect άδειες στο κατάστημα.nowbe4.com. Ερευνούμε αυτό το θέμα και θα ενημερώσουμε αυτή τη σελίδα όταν έχουμε περισσότερες πληροφορίες.

4. 29 Ιουλίου 2026 στις 6:40 μ.μ. UTCmonitoring

   Έχουμε εφαρμόσει ένα fix για το ηλεκτρονικό κατάστημα και παρακολουθούμε τα αποτελέσματα για να διασφαλίσουμε ότι δεν θα προκύψουν περαιτέρω ζητήματα.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 16 Ιουλίου 2026 στις 7:48 μ.μ. UTCinvestigating

   Έχουμε εντοπίσει ένα ζήτημα όπου οι χρήστες μπορούν να λάβουν μια ανακατευθύνει κατά την είσοδο σε Υπεράσπιση, και η ομάδα μηχανικής μας εξετάζει σε μια λύση.

2. 16 Ιουλίου 2026 στις 8:09 μ.μ. UTCidentified

   Αναγνωρίστηκε μια λύση, και θα παρακολουθούμε τα αποτελέσματα καθώς θα προχωρά.

3. 16 Ιουλίου 2026 στις 9:20 μ.μ. UTCresolved

   Το περιστατικό λύθηκε.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 15 Ιουλίου 2026 στις 4:51 μ.μ. UTCinvestigating

   Ερευνούμε χρήστες που δεν είναι σε θέση να αγοράσουν Protect άδειες στο κατάστημα.nowbe4.com. Θα ενημερώσουμε αυτή τη σελίδα όταν έχουμε περισσότερες πληροφορίες.

2. 15 Ιουλίου 2026 στις 4:54 μ.μ. UTCinvestigating

   Συνεχίζουμε να ερευνούμε αυτό το ζήτημα.

3. 16 Ιουλίου 2026 στις 1:23 π.μ. UTCmonitoring

   Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.

4. 16 Ιουλίου 2026 στις 2:04 μ.μ. UTCresolved

   Το περιστατικό λύθηκε.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 22 Ιουλίου 2026 στις 9:01 μ.μ. UTCresolved

   Ένα ανάντη χαρακτηριστικό χαρακτηριστικό χαρακτηριστικό υπηρεσία υποβαθμισμένη routing μοντέλο σε συνεργασία-συμπέρανα, προκαλώντας αξιολογήσεις PhishML να επιστρέψει 0/0/0 προεπιλεγμένα λάθη. Το τρίτο μέρος ανέπτυξε μια επιδιόρθωση, και μια ενημέρωση κώδικα αναπτύχθηκε για την παραγωγή προσθέτοντας στατική εφεδρική δρομολόγηση. Όλες οι υπηρεσίες έχουν ανακάμψει και λειτουργούν κανονικά.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 1 Ιουλίου 2026 στις 2: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 Ιουλίου 2026 στις 4:02 μ.μ. UTCmonitoring

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

3. 1 Ιουλίου 2026 στις 6:01 μ.μ. UTCresolved

   This incident has been resolved.

4. 8 Ιουλίου 2026 στις 6: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 Ιουνίου 2026 στις 4: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 Ιουνίου 2026 στις 7:46 μ.μ. UTCresolved

   This incident has been resolved.

3. 3 Ιουλίου 2026 στις 3: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 Ιουνίου 2026 στις 2:18 μ.μ. UTCinvestigating

   Έχουμε εντοπίσει ένα θέμα όπου οι αξιολογήσεις PhishML προκαλούν την ετικέτα "PML:BYPASSED" που πρέπει να εφαρμοστεί.

2. 30 Ιουνίου 2026 στις 3:42 μ.μ. UTCmonitoring

   Έχουμε εφαρμόσει μια λύση για PhishER και παρακολουθούμε τα αποτελέσματα για να διασφαλίσουμε ότι δεν θα προκύψουν περαιτέρω ζητήματα. Τα αντικρουόμενα μηνύματα μπορούν να αναπαραχθούν μέσω όλων των κανόνων και ενεργειών. Παρακαλούμε να γνωρίζετε ότι αυτό μπορεί να προκαλέσει την αποστολή διπλών απαντήσεων σε περίπτωση που μια ενέργεια εκτελέστηκε επιτυχώς κατά τη διάρκεια αυτού του περιστατικού. Εάν έχετε περισσότερες ερωτήσεις ή ανησυχίες παρακαλούμε επικοινωνήστε απευθείας με την ομάδα υποστήριξης μας: https://support.nowbe4.com/hc/en-us/quests/new Το ακόλουθο άρθρο της βάσης γνώσεων περιέχει οδηγίες για τον τρόπο επανάληψης των μηνυμάτων: https://support.nowbe4.com/hc/en-us/articles/13169303385619-PhishER-Inbox-guide#h 01HCNEBF8CJ98GE9PGM7HGDZ0

3. 30 Ιουνίου 2026 στις 7:11 μ.μ. UTCresolved

   Το περιστατικό λύθηκε.

4. 22 Ιουλίου 2026 στις 1:20 μ.μ. UTCpostmortem

   Την Τρίτη 30 Ιουνίου 2026, από περίπου 07:40 έως 19:15 \(UTC\), οι πελάτες γνώρισαν λανθασμένα αποτελέσματα από τη βαθμολογία PhishER's PhishML. Προσβλημένα emails έλαβαν μια ετικέτα PML: BYPASSED αντί για μια νόμιμη ταξινόμηση PhishML, και βαθμολογία εμπιστοσύνης έλειπαν από τα μηνύματα που είχαν αντίκτυπο. Κανόνες και δράσεις που εξαρτώνται από τα αποτελέσματα PhishML επίσης δεν ενεργοποιήθηκαν. Το θέμα αυτό προκλήθηκε από έναν αναπαράγοντα κώδικα που εισήχθη περίπου δύο εβδομάδες νωρίτερα. Αυτός ο συντελεστής εισήγαγε μια ελαττωματική ενημέρωση που παρέλειψε βασικές οδηγούς που απαιτούνται για τη βαθμολόγηση PhishML για να τρέξει. Ωστόσο, το ζήτημα παρέμεινε αδρανές μέχρις ότου μια άλλη ενημέρωση προκάλεσε μια νέα ανάπτυξη μοντέλου PhishML, η οποία προκάλεσε την εμφάνιση του θέματος βαθμολόγησης. Για την επίλυση αυτού του ζητήματος, η ομάδα μας επέστρεψε στην τελευταία σταθερή ανάπτυξη και πρόσθεσε περισσότερη ικανότητα να επεξεργαστεί το επακόλουθο backlog των αξιολογήσεων ηλεκτρονικού ταχυδρομείου. Η βαθμολογία PhishER's PhishML επέστρεψε στην κανονική απόδοση μέχρι τις 19:15 \(UTC\). Για την πρόληψη αυτού του είδους των ζητημάτων στο μέλλον, βελτιώσαμε τους υγειονομικούς ελέγχους εισάγοντας ένα νέο τελικό σημείο για τη δοκιμή καπνού νέα μοντέλα πριν από την ανάπτυξη.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 24 Ιουνίου 2026 στις 3: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 Ιουνίου 2026 στις 10: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 Ιουνίου 2026 στις 1: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 Αυγούστου 2026 στις 2: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 Ιουνίου 2026 στις 9: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 Ιουνίου 2026 στις 9:16 μ.μ. UTCinvestigating

   We are continuing to investigate this issue.

3. 18 Ιουνίου 2026 στις 10:42 μ.μ. UTCmonitoring

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

4. 19 Ιουνίου 2026 στις 2:01 μ.μ. UTCresolved

   This incident has been resolved.

5. 7 Ιουλίου 2026 στις 7: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 Ιουνίου 2026 στις 3: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 Ιουνίου 2026 στις 3: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 Ιουνίου 2026 στις 7:12 μ.μ. UTCresolved

   This incident has been resolved.

1. 16 Ιουνίου 2026 στις 10:23 μ.μ. UTCinvestigating

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

2. 17 Ιουνίου 2026 στις 12:48 μ.μ. UTCmonitoring

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

3. 17 Ιουνίου 2026 στις 8:19 μ.μ. UTCresolved

   This incident has been resolved.

1. 15 Ιουνίου 2026 στις 4:56 μ.μ. UTCresolved

   This incident has been resolved.

1. 3 Ιουνίου 2026 στις 3:07 μ.μ. UTCinvestigating

   Έχουμε λάβει αναφορές για 500 λάθη που συμβαίνουν κατά την πλοήγηση σε προφίλ χρηστών. Ερευνούμε αυτό το θέμα και θα ενημερώσουμε αυτή τη σελίδα όταν έχουμε περισσότερες πληροφορίες.

2. 3 Ιουνίου 2026 στις 4:16 μ.μ. UTCmonitoring

   Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.

3. 3 Ιουνίου 2026 στις 6:14 μ.μ. UTCresolved

   Το περιστατικό λύθηκε.

4. 15 Ιουλίου 2026 στις 3:23 μ.μ. UTCpostmortem

   Την Τετάρτη 3 Ιουνίου 2026, από περίπου 14:49 έως 16:09 \(UTC\), οι πελάτες παρουσίασαν λάθη κατά την πρόσβαση στη σελίδα **Χρήστης Λεπτομέρειες*** στην κονσόλα KSAT. Το θέμα αυτό προκλήθηκε από μια ενημέρωση που εισήγαγε τα ελλείποντα πεδία, τα οποία απέτρεψαν τη φόρτωση της σελίδας **Χρήστης Λεπτομέρειες**. Για την επίλυση αυτού του ζητήματος, η ομάδα μας ενημέρωσε την κονσόλα και πάλι για να αποκαταστήσει τα ελλείποντα πεδία, και η κονσόλα KSAT επέστρεψε στην κανονική απόδοση κατά περίπου 16:09 \(UTC\). Για να αποφευχθούν παρόμοια ζητήματα στο μέλλον, προστέθηκαν επιπλέον αυτοματοποιημένες δοκιμές. Δεν προέκυψε απώλεια δεδομένων ως αποτέλεσμα αυτού του τεύχους.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 28 Μαΐου 2026 στις 6:17 μ.μ. UTCinvestigating

   We are currently investigating an issue preventing customers from uploading custom content to the new Modstore

2. 28 Μαΐου 2026 στις 7:13 μ.μ. UTCresolved

   We have identified an issue with uploading custom content to the new Modstore and implemented a fix. Customers should be able to upload custom content successfully.

3. 7 Ιουλίου 2026 στις 7:43 μ.μ. UTCpostmortem

   On Thursday, May 28, 2026, from approximately 18:07 to 18:57 \(UTC\), some customers experienced issues uploading custom content to the new ModStore in KnowBe4 Security Awareness Training \(KSAT\). This issue was caused by an update to the new ModStore that disabled the language selection field in the “Add Translation” upload step, preventing customers from completing that required part of the upload process. To resolve this issue, our engineering team identified the recent deployment responsible for the defect, corrected it, and deployed the update to production. KSAT returned to normal performance by 18:57 \(UTC\). To prevent this type of issue in the future, we are improving test coverage for the affected upload flow and adding automated checks to catch similar issues before they reach production. No data loss occurred as a result of this issue.

1. 27 Μαΐου 2026 στις 10:05 π.μ. UTCinvestigating

   We have received reports that there is a Intermittent issue sending emails for Protect. We are investigating this issue and will update this page when we have more information.

2. 27 Μαΐου 2026 στις 2:39 μ.μ. UTCmonitoring

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

3. 27 Μαΐου 2026 στις 3:44 μ.μ. UTCresolved

   This incident has been resolved.

1. 21 Μαΐου 2026 στις 1:40 μ.μ. UTCidentified

   We've received reports that customers are unable to access the new Modstore experience and are receiving 500 errors. We are investigating these issues and will update this page when we have more information.

2. 21 Μαΐου 2026 στις 1:41 μ.μ. UTCmonitoring

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

3. 21 Μαΐου 2026 στις 5:20 μ.μ. UTCresolved

   This incident has been resolved.

4. 7 Ιουλίου 2026 στις 3:32 μ.μ. UTCpostmortem

   # **Summary** On Wednesday, May 21, 2026, customers using the new ModStore experience within KnowBe4 Security Awareness Training \(KSAT\) were unable to access the ModStore and received HTTP 500 errors. The disruption affected all regional instances and lasted approximately 23 minutes, from 13:17 to 13:40 \(UTC\). This issue was caused by a defective code change in a routine ModStore deployment. The deployment itself completed successfully, but the change caused the application to return server errors when customers attempted to load the new ModStore. Our engineering team identified the faulty deployment within minutes, rolled it back, and confirmed full restoration of service at 13:40 \(UTC\). Only the new ModStore experience was affected. Customers using the classic ModStore, and all other KSAT functionality — including training assignments, campaigns, and reporting — remained fully operational throughout. There was no data loss as a result of this incident. # **What Happened** ## **New ModStore \(KSAT\)** At 13:08 \(UTC\) on May 21, 2026, a routine deployment of the new ModStore application began and was completed successfully across all production environments at 13:17 \(UTC\). The release included changes related to integrating the new ModStore natively into the KnowBe4 platform. Immediately following the deployment, the new ModStore began returning HTTP 500 errors to customers attempting to access it. At 13:28 \(UTC\), internal reports of the errors reached the engineering team, and by 13:30 \(UTC\) engineers had correlated the failures with the deployment. The decision to roll back was made at 13:31 \(UTC\). At 13:32 \(UTC\), with multiple customer support tickets confirming customer-facing impact, a high-severity incident was declared, and on-call engineers were contacted. The team quickly confirmed the scope: only the new ModStore experience, enabled for approximately half of customers plus those who had opted in, was affected, across all regional instances. The classic ModStore and all other KSAT functionality remained available. A rollback to the previous stable version was initiated at 13:35 \(UTC\) and completed at 13:40 \(UTC\), at which point access to the new ModStore was fully restored. Our public status page was updated at 13:40 \(UTC\) and moved to “Monitoring” one minute later. During the post-restoration investigation, an engineer noted that a separate infrastructure-as-code deployment earlier that morning had unexpectedly altered a storage Cross-Origin Resource Sharing \(CORS\) configuration used by the ModStore. This change was investigated as a potential contributor and ruled out — it was not related to the 500 errors. The investigation did, however, surface that two separate deployment pipelines were both managing the same infrastructure configuration and silently overwriting each other’s changes. This conflict was remediated during the incident window by assigning the configuration a single owning pipeline. After continued monitoring confirmed stability, the incident was resolved internally at 14:52 \(UTC\), and the public status page was updated to “Resolved” at 17:20 \(UTC\). # **Root Cause Analysis** The root cause of this incident was a defective code change included in the 13:17 \(UTC\) deployment of the new ModStore application. Once deployed, the change caused the application to fail to serve customer requests, returning HTTP 500 errors to all users of the new ModStore experience across all regions. The defect was not detected during pre-deployment testing, so the deployment proceeded to production as usual. Because the failure began at the moment the deployment completed and affected all regions simultaneously, engineers were able to identify the deployment as the trigger within minutes and end customer impact by rolling back to the previous version. The faulty change was withheld for rework and additional validation before any reintroduction. A secondary issue was identified during the investigation: an unrelated infrastructure configuration change that morning initially appeared connected because of its timing. It was ruled out as a cause, but the investigation revealed that two deployment pipelines shared ownership of the same infrastructure configuration and were overwriting each other. While this did not cause the incident, it added noise to the diagnosis. Because it represented a latent risk, it was also corrected the same day. ## **Detailed Timeline \(UTC\)** | **Time \(UTC\)** | **Event** | | --- | --- | | **13:08** | A routine deployment to the new ModStore application begins. | | **13:17** | The deployment completes across all production environments; HTTP 500 errors begin for the new ModStore experience. | | **13:28** | Internal reports of errors loading the new ModStore reach the engineering team. | | **13:30** | Engineers correlate the HTTP 500 errors with the earlier deployment. | | **13:31** | Decision made to roll back the deployment. | | **13:32** | A high-severity incident is declared; on-call engineers are paged. Customer support tickets confirm customer-facing impact. | | **13:33 – 13:34** | Impact confirmed to be limited to the new ModStore experience; the classic ModStore and all other KSAT functionality are confirmed unaffected. All regional instances are affected. | | **13:35 – 13:38** | The revert is prepared, and the rollback deployment begins. | | **13:40** | Rollback completes, and access to the new ModStore is restored. The public status page is updated to “Identified.” | | **13:41** | The public status page is updated to “Monitoring.” | | **13:58 – 14:11** | An unrelated same-morning infrastructure configuration change is investigated and ruled out as a cause. A conflicting ownership issue between two deployment pipelines that manage the same configuration is identified and remediated. | | **14:52** | After continued monitoring confirms stability, the incident is marked resolved internally \(74 minutes after the incident was declared\). | | **17:20** | The public status page is updated to “Resolved.” | ‌ # **Findings and Mitigations** ## **1. A defective change reached production** A code change included in a routine deployment of the new ModStore caused the application to return server errors in production. The defect was not caught by the automated tests that run before a release is promoted, indicating a gap in pre-deployment test coverage for this failure mode. **Mitigations:** * The deployment was rolled back within 23 minutes of impact beginning, immediately restoring service. * The faulty change was withheld from redeployment pending rework and additional validation. * Pre-deployment test coverage for the new ModStore is being expanded to cover the failure mode seen in this incident. ## **2. Detection relied on human reports rather than automated alerting** Impact began at 13:17 \(UTC\), but the engineering team was first engaged through internal reports at 13:28 \(UTC\) and customer support tickets shortly after, rather than by an automated alert on the application’s error rate. Automated post-deployment checks that ran after the release did not halt the rollout or page the team. **Mitigations:** * Error-rate monitoring and automated alerting for the new ModStore are being strengthened so that a spike in server errors immediately after a deployment pages the on-call team directly. * Post-deployment verification is being reviewed so that failing checks more decisively block or flag a release. ## **3. Two deployment pipelines managed the same infrastructure configuration** The application’s deployment pipeline and a separate infrastructure-as-code pipeline both defined the same storage CORS configuration, and each deployment silently overwrote the other’s settings. This conflict was not the cause of the incident, but it initially complicated diagnosis and represented an ongoing risk of unintended configuration changes. **Mitigations:** * The duplicated configuration was removed from the application pipeline and its state references were cleaned up, making the infrastructure pipeline the single owner of that configuration. * A review is underway to identify any other resources with shared ownership across pipelines. # **Customer Impact** ## **KSAT – New ModStore \(all regions\)** From 13:17 to 13:40 \(UTC\), customers who had the new ModStore experience enabled \(approximately half of customers, plus those who opted in\) received HTTP 500 errors when attempting to access the ModStore and were unable to browse or add training content during that window. All regional instances were affected equally. Customers using the classic ModStore were not affected. All other KSAT functionality — including active training campaigns, phishing simulations, user enrollments, and reporting — operated normally throughout the incident. No customer action was or is required, and no data was lost or altered. # **Preventive Measures** * **Expanded pre-deployment testing —** Test coverage for the new ModStore is being extended to catch the class of defect that caused this incident before a release reaches production. * **Automated error-rate alerting —** Monitoring on the new ModStore is being strengthened so that elevated server-error rates following a deployment automatically notify on-call engineers, removing the dependency on human reports for detection. * **Stronger post-deployment verification —** The automated checks that run immediately after a release are being reviewed so that failures block or escalate a rollout rather than passing silently. * **Single ownership of infrastructure configuration —** Shared infrastructure settings are being consolidated under a single owning pipeline to prevent conflicting automated changes, and an audit is underway to identify any remaining overlaps. # **Conclusion** On May 21, 2026, a defective code change during a routine deployment made the new ModStore experience unavailable for approximately 23 minutes, resulting in server errors for affected customers across all regions. We recognize that the ModStore is central to how administrators build their training programs, and we apologize for the disruption. The response demonstrated the value of fast rollback as a recovery path: the faulty release was identified and reverted within minutes of the first reports, the scope was accurately confirmed early, and no data was lost. The incident also highlighted clear opportunities to improve: stronger pre-deployment testing, automated error-rate detection, and cleaner ownership of infrastructure configuration. These are being addressed through the preventive measures above. We are committed to the reliability of the new ModStore experience as it rolls out to all customers, to ensuring that issues of this kind are caught before they reach production, and to detecting and resolving issues automatically if they do reach production.

1. 19 Μαΐου 2026 στις 2:16 μ.μ. UTCidentified

   We are seeing errors when using the Microsoft Ribbon Phish Alert Button (PAB) to report emails in Classic Outlook. Our team is aware and investigating these errors.

2. 19 Μαΐου 2026 στις 3:25 μ.μ. UTCmonitoring

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

3. 19 Μαΐου 2026 στις 6:04 μ.μ. UTCresolved

   This incident has been resolved.

4. 25 Ιουνίου 2026 στις 6:38 μ.μ. UTCpostmortem

   From Monday, May 18, 2026, at approximately 14:00 \(UTC\), to Tuesday, May 19, 2026, at approximately 15:00 \(UTC\), users experienced timeouts when attempting to use the Microsoft Ribbon Phish Alert Button \(PAB\) in Classic Outlook. This issue was caused by an update to the PAB's authentication process that was incompatible with the Classic Outlook environment. The update used a loading method that Classic Outlook does not support, which caused the PAB to time out before it could connect to KnowBe4's servers.  To resolve this issue, we updated how the authentication library is packaged with the PAB to ensure compatibility with Classic Outlook. The Microsoft Ribbon PAB returned to normal performance by approximately 15:00 \(UTC\) on May 19, 2026. To prevent this type of issue in the future, we are updating our processes for compatibility testing and improving monitoring. No data loss occurred as a result of this issue.