46 Cycode incidents · février 2026 — official updates, affected components, duration and resolution details.
GitHub component: Pull Requests Original GitHub incident: https://stspg.io/ssd9z8l2g46v
GitHub component: Pull Requests Original GitHub incident: https://stspg.io/ssd9z8l2g46v
Traduit automatiquement depuis la mise à jour officielle de l'incident.
GitHub component: API Requests Original GitHub incident: https://stspg.io/3xn46bst0bjh
GitHub component: API Requests Original GitHub incident: https://stspg.io/3xn46bst0bjh
GitHub component: API Requests Original GitHub incident: https://stspg.io/3xn46bst0bjh
Les clients peuvent éprouver des performances dégradées dans les scans. La demande de tirage et les analyses CLI peuvent être affectées.
The team has identified the root cause of the issue and is working on the solution.
The root cause has been resolved. The system began to stabilize itself, and all the scans are starting to get processed with regular performance.
All scan types except for SAST are fully operational. SAST continues to stabilize and will soon be fully stable.
Le système devrait être de nouveau pleinement opérationnel.
**Root Cause** The incident was caused by a deployment of one service that ran a database index creation. The team has identified an issue with the way we perform index creations as database migrations. During a deployment the pods with newest image of the service attempted to create an index on a big table. The team has identified that the index creation took 7 minutes. However, during index creation pods were not responsive, and as a result, Kubernetes deemed them as unhealthy pods and attempted to retry those pods after 5 minutes. As a result, because the pod got killed before the index creation was fully completed, the database transaction was rolled back. Then, subsequent pods attempted to create the index again, dying after 5 minutes. This lead to the database being in unhealthy state, and the service was down. The team has rolled back the deployment, and killed all replicas that attempted to create the index. Thanks to that, the service and the database was in healthy state again. **Why safety measures did not help** Cycode provides a safety mechanism that unblocks all Pull Request scans after a specific period of time, giving each scan a maximum duration before the Pull Request is unblocked. However, because the service that is responsible for triggering and completing scans, as well as this safety net, was down, the process couldn't behave as expected. We acknowledge this gap and are working on strengthening this area of our system. **Action items** • The team is actively investigating enhancements and new safety protocols that can be put in place in order to have another safety net preventing Pull Request scans being stuck in case of any incident. • The team is investigating changes to the index creation process.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons sur un problème qui provoque la retraite des événements plus anciens. **Impact:** Certains workflows peuvent être exécutés à nouveau, ce qui pourrait entraîner des alertes en double. Les scans PR peuvent également être retardés.
Nous avons résolu l'arriéré de traitement causé par un problème lors d'une migration de Kafka. La question a entraîné le traitement des événements plus anciens en même temps que de nouveaux événements, ce qui a entraîné des retards et peut avoir mis à jour certaines violations avec un statut dépassé. Le traitement normal a été rétabli. Cependant, les clients peuvent encore voir certaines violations avec un statut dépassé pendant que nous identifions et corrigeons les dossiers touchés. Les scans de RP n'ont pas été retardés ni retraités, et les flux de travail n'ont pas été touchés. Nous poursuivons les travaux de remise en état et nous suivons de près le système.
Le traitement normal a été rétabli et l'incident est en cours de surveillance. Un petit nombre de clients peuvent encore voir un nombre limité de violations avec un statut dépassé à la suite de l'incident. Nous avons identifié les environnements potentiellement touchés et nous travaillons à corriger les dossiers touchés.
Le système est pleinement opérationnel. Un petit nombre de clients peuvent encore voir un nombre limité de violations avec un statut dépassé à la suite de l'incident. Nous avons identifié les environnements potentiellement touchés et nous travaillons à corriger les dossiers touchés.
The platform is now fully operational and processing normally
Traduit automatiquement depuis la mise à jour officielle de l'incident.
L'équipe a identifié un problème avec des performances dégradées avec balayage. Il peut y avoir des retards dans le démarrage, l'exécution et la réalisation des scans. Tous les types de scan peuvent être affectés (requête de tirage et scans CLI aussi). L'équipe a identifié un problème avec un dysfonctionnement du déploiement, et le problème devrait être résolu sous peu.
L'équipe a identifié la cause profonde et l'a résolue. Nous voyons le système revenir à la stabilité.
Le système est maintenant de nouveau pleinement opérationnel.
** Cause de la mort** L'incident a été causé par le déploiement d'un service qui a effectué une migration de base de données. L'équipe a constaté que cette migration contenait un code défectueux et, par conséquent, entraîne une surcharge de base de données lorsqu'elle tente de déployer le service. En conséquence, le service a été partiellement réduit jusqu'à ce que le déploiement soit rétabli. Pendant cette période, tous les scans ont été traités avec des performances inférieures aux attentes.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Composant GitHub : Demandes d'API L'incident initial de GitHub: https://stspg.io/vr201n49yl53
Composant GitHub : Demandes d'API L'incident initial de GitHub: https://stspg.io/vr201n49yl53
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/sm1tp7kfm4vj
Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/sm1tp7kfm4vj
Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/sm1tp7kfm4vj
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons remarqué des performances dégradées dans les scans IaC Pull Request. Nous dépêchons le problème.
Nous avons identifié la cause profonde de la lenteur et mettons en place des contre-mesures.
Le décalage qui a conduit à la lenteur est presque terminé. Nous suivons la situation.
La question a été réglée et nous continuons de suivre la situation.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Composant GitHub : Demandes d'API, Demandes de tirage L'incident initial de GitHub: https://stspg.io/j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Composant GitHub: Webhooks L'incident initial de GitHub: https://stspg.io/syhr80rth84z
Composant GitHub: Webhooks, Demandes de tirage L'incident initial de GitHub: https://stspg.io/syhr80rth84z
Composant GitHub: Webhooks, Demandes de tirage L'incident initial de GitHub: https://stspg.io/syhr80rth84z
Traduit automatiquement depuis la mise à jour officielle de l'incident.
À **1:41** PM EDT, nous avons identifié un problème causant des taux d'erreurs élevés pendant le traitement des demandes dans l'interface utilisateur plate-forme. La question a été atténuée rapidement, et la plateforme fonctionne actuellement normalement. Notre équipe continue de surveiller activement la plateforme pour assurer la stabilité du service.
L'incident a été résolu et la plateforme fonctionne normalement.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons remarqué qu'une partie des secrets de l'ICL échoue. Nous trions activement le problème.
Nous avons identifié que CLI version 3.17.1 a introduit le comportement défectueux. Dégrader la version de l'ICL de 3.17.0 devrait résoudre temporairement le problème pendant que nous continuons de comprendre et de résoudre la cause fondamentale.
Un correctif a été appliqué et la fonctionnalité est entièrement restaurée; nous continuons à surveiller pour nous assurer que tout reste stable.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
En raison de l'augmentation des charges de balayage, nous avons observé des retards dans les mises à jour de l'état de violation, qui comprennent la résolution automatique des violations. La source de cette augmentation soudaine a été atténuée et le retard diminue déjà. Nous continuerons à surveiller la situation jusqu'à ce que nous revenions à la normale
Nous continuons de surveiller le traitement de la détection et les retards associés dans les mises à jour de l'état de la violation (y compris la résolution automatique)
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons remarqué des performances dégradées dans plusieurs composants du système. Nous identifions tous les composants touchés et la cause profonde.
Nous avons remarqué des performances dégradées dans plusieurs composants de l'interface utilisateur d'application. Les analyses, ainsi que les requêtes de tirage et les analyses CLI peuvent également être affectées.
Nous observons des taux élevés de temps d'attente de Redis. Nous rehaussons la capacité des grappes Redis d'atténuer l'impact et de rétablir une performance de service stable
La région s'est rétablie et fonctionne normalement. Nous surveillons de près les performances du système pour assurer une stabilité continue
Le système est maintenant pleinement opérationnel. Il ne devrait pas y avoir plus de performance dégradée. ** Résumé** Nous avons observé une période de lenteur et de délais intermittents affectant diverses fonctions du système dans la région de l'UE, y compris l'interface d'application et l'analyse des requêtes de traction (PR). La question était principalement causée par un système de traitement atteignant ses limites de capacité de réseau et de mémoire, exacerbé par un volume élevé d'activités automatisées provenant d'une seule source. Depuis, nous avons amélioré l'infrastructure sous-jacente et mis en place des mesures de protection afin d'empêcher que des activités aussi importantes n'aient des répercussions sur le système. La question est maintenant entièrement résolue et tous les services ont retrouvé les niveaux de rendement prévus. **Échéancier clé (IDT)** • **13 juillet 2026, 11 h 44 IDT**: Incident détecté à la suite de rapports de lenteur de l'assurance-chômage et de retards dans l'analyse des PR. • **13 juillet 2026, 12:19 IDT**: Le goulot d'étranglement de l'infrastructure a été identifié; la décision a été prise d'améliorer la grappe de traitement. • **13 juillet 2026, 12 h 26 Un processus automatisé à volume élevé a été identifié et désactivé pour réduire la charge immédiate. • **13 juillet 2026, 13 h 09 IDT**: Mise à niveau de l'infrastructure terminée; le débit du réseau est revenu à des niveaux normaux. • **13 juillet 2026, 15 h 35 Tous les arriérés ont été réglés et l'incident a été officiellement réglé. ** Cause de la mort** L'incident a été déclenché par une combinaison de facteurs : un groupe de traitement a atteint sa bande passante maximale du réseau et sa capacité de mémoire en raison d'une configuration sous-dimensionnée pour la charge de travail actuelle. Cela a été aggravé par un flux de travail automatisé spécifique qui a généré un volume exceptionnellement élevé de demandes de mise à jour. En outre, une différence de configuration dans le pipeline de traitement des messages dans la région de l'UE a empêché le système de traiter efficacement l'arriéré qui en a résulté. **Mesures prises** • **Infrastructures améliorées**: La grappe de traitement a été mise à niveau pour devenir un type d'instance de plus grande capacité afin de fournir plus de bande passante et de mémoire réseau. Source** : Un identifiant client spécifique responsable d'un trafic excessif a été temporairement désactivé pour rétablir la stabilité du système. • **Restaurer la connectivité** : les composantes de service touchées ont été redémarrées pour s'assurer qu'elles ont rétabli des connexions propres à l'infrastructure améliorée. • **Parallélisme de traitement accru**: Le nombre de partitions dans la file d'attente des messages touchés a été augmenté pour permettre au système de traiter l'arriéré plus rapidement. ** Mesures à prendre** • **Surveillance de l'Enhance**: Mettre en place de nouvelles alertes pour l'utilisation du réseau et de la mémoire afin de détecter les problèmes de capacité avant qu'ils n'aient un impact sur les clients. • **Optimiser le flux de travail de mise à jour**: Refactorer le processus de mise à jour de l'état aux demandes de lot, réduisant considérablement la charge sur le système de traitement. • **Limitation du taux d'exécution**: introduire des mesures de protection pour empêcher toute source unique de consommer des ressources du système disproportionnées. • ** Normaliser les configurations régionales**: Effectuer une vérification pour s'assurer que les paramètres d'infrastructure et de file d'attente des messages sont uniformes dans toutes les régions.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous avons identifié un problème qui peut causer **dénombrements de violations inexacts** dans **des tableaux de bord de produits et des tableaux de bord personnalisés qui reposent sur des données de violation (tous les tableaux de bord ne sont pas affectés). Nous avons déjà commencé le travail de correction, mais il faudra du temps pour terminer complètement, et vous pouvez voir les chiffres changer lorsque les données sont corrigées. Nous partagerons une autre mise à jour une fois que la correction a fini d'exécuter et la précision des données est entièrement restaurée.
Nous avons fait des progrès importants dans la correction des comptes de violation inexacts affectant certains produits et tableaux de bord personnalisés. • ** État actuel :** La correction a été effectuée avec succès pour la grande majorité des comptes, et l'exactitude complète des données a été rétablie. • **Prochaines étapes:** Nous résolvons activement la question du petit nombre de comptes restants touchés.
La fonctionnalité est entièrement restaurée; nous continuons de surveiller pour nous assurer que tout reste stable.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons actuellement sur une question touchant l'Explorabilité des risques de Maestro, l'assainissement des risques d'IA, l'assainissement des Maestro et les services d'IA de Graph.
Nous avons identifié un problème de configuration du pare-feu qui impactait les services de Maestro AI. La configuration a été mise à jour, et les services touchés ont récupéré. Nous continuons de suivre la situation et nous travaillons à une stabilisation plus poussée. Certaines performances dégradées peuvent encore être observées pendant que nous complétons des améliorations supplémentaires.
La question des services d'IA Maestro a été résolue. Explorabilité du risque Maestro, restauration du risque AI, restauration du risque Maestro et l'IA graphique sont maintenant disponibles et fonctionnent normalement. ** Résumé** Le 9 juillet 2026, les clients utilisant le service Maestro dans l'environnement de production européen ont connu une période d'indisponibilité du service. Le problème a commencé après une mise à jour de configuration qui a modifié par inadvertance le routage régional du service. Cela a amené le système à tenter des connexions par un chemin de réseau qui n'avait pas les autorisations nécessaires et vers une région où des modèles de traitement spécifiques n'étaient pas disponibles. Le problème a été entièrement résolu et le service a été rétabli pour tous les clients touchés. **Échéancier clé (IDT)** • **9 juillet 2026, 12 h 02 L'incident a été identifié et une enquête a été ouverte. • **Le 9 juillet, 2026, 12:07 IDT:** Un avis public a été émis concernant l'interruption de service. • **Le 9 juillet 2026, 13 heures Une correction de configuration réseau a été appliquée, rétablissant la connectivité primaire. • **9 juillet 2026, 13 h 39 Le service a été entièrement rétabli après la mise en oeuvre des modèles de repli, et l'incident a été marqué comme résolu. ** Cause de la mort** L'interruption du service a été déclenchée par une mise à jour récente du processus d'authentification et de configuration. Cette mise à jour a créé un conflit dans la façon dont le système a identifié sa région opérationnelle. Plus précisément, un processus de mise à jour automatisé dépasse les paramètres manuels, acheminant le trafic vers un paramètre régional différent. Ce nouveau chemin a été bloqué par une règle de sécurité du réseau manquante et a tenté d'utiliser un modèle de traitement qui n'était pas pris en charge dans cette région spécifique, ce qui a entraîné une panne de service. **Mesures prises** • **Résoudre la connectivité du réseau:** Mise à jour manuelle des règles de sécurité du réseau pour permettre un trafic sécurisé par le nouveau paramètre régional. • **Modèle mis en œuvre Retours en arrière:** Configurer le système pour utiliser d'autres modèles de traitement afin d'assurer la disponibilité immédiate du service pendant que les configurations régionales à long terme étaient ajustées. • **Mise à jour : Mise à jour en temps réel pour les intervenants et les clients tout au long du processus de récupération. ** Mesures à prendre** • ** Normaliser la priorité de configuration :** Mettre à jour le flux de travail de déploiement pour éviter que les processus automatisés ne dépassent silencieusement les paramètres d'environnement critique. • ** Audit des infrastructures :** Effectuer un examen complet des règles de sécurité des réseaux dans toutes les régions afin d'assurer la cohérence et d'éviter des lacunes similaires en matière de connectivité. • **Surveillance automatisée du renforcement :** Mettre en oeuvre des contrôles de santé de bout en bout et des sondes synthétiques pour détecter automatiquement les problèmes de connectivité régionale avant qu'ils n'aient un impact sur les utilisateurs. • **Améliorer les politiques de déploiement :** Établir de nouvelles lignes directrices pour s'assurer que les changements de configuration sont déployés et validés plus fréquemment dans des environnements de production afin de réduire le risque de mises à jour "existantes".
Traduit automatiquement depuis la mise à jour officielle de l'incident.
We are experiencing delays in infrastructure provisioning caused by cloud provider API rate limiting. We are actively investigating the issue with our cloud provider.
Please refer to the AWS Health Status page for details on the related incident: [https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status "https://health.aws.amazon.com/health/status")
Mitigation: We temporarily scaled up the managed node group to get pods scheduled while we wait for AWS to fully resolve the underlying issue.
We are starting to see stabilization and a reduction in API errors. However, we continue to closely monitor the situation.
AWS has confirmed that the issue has been fully mitigated and we are currently not observing any related issues.
**Enquête - Questions relatives aux violations et aux tableaux de bord sur mesure (Prod-US)** Nous enquêtons actuellement sur un problème dans notre environnement **Prod-US** où les violations ne sont pas chargées. Par conséquent, les panneaux de tableau de bord personnalisés qui s'appuient sur les données de violation peuvent également ne pas rendre ou afficher des erreurs. Notre équipe d'ingénierie s'intéresse activement à la cause fondamentale, et nous fournirons des mises à jour ici au fur et à mesure que nous en apprendrons davantage. Nous nous excusons pour le désagrément.
Une correction a été déployée pour les problèmes touchant les violations et les tableaux de bord personnalisés dans Prod-US. Nous surveillons activement l'environnement pour nous assurer que les services sont entièrement rétablis.
La question fondamentale a été résolue et les violations et les tableaux de bord personnalisés devraient maintenant fonctionner normalement. Notre équipe surveille activement la synchronisation des données afin de résoudre les éventuelles divergences avec les nouvelles violations. Nous fournirons une mise à jour finale une fois la synchronisation terminée.
Nous continuons de surveiller le processus de synchronisation des données pour les nouvelles infractions à l'assurance-chômage. Bien que la fonctionnalité ait été rétablie, il faudra peut-être jusqu'à **6 heures** pour que toutes les données récentes soient complètement retracées et réfléchies avec précision. Nous fournirons une mise à jour finale une fois la synchronisation terminée.
La synchronisation des données est terminée, et toutes les violations récentes ont été comblées avec succès par l'assurance-chômage. Les violations et les tableaux de bord personnalisés fonctionnent normalement, et l'incident est entièrement résolu. Nous apprécions votre patience dans nos efforts pour rétablir le service complet.
La fonctionnalité est entièrement restaurée; nous continuons de surveiller pour nous assurer que tout reste stable.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
We have identified the source of an issue and currently deploying the fix. At the same time we scaled our scanning platform up to accelerate scanning
The fix was deployed. The queue is decreasing and we're monitoring it
The system has processed all jobs with higher priorities. There is a queue of lower priority jobs that should not impact overall Cycode scanning performance
**Summary** During the incident, customers experienced significant delays and temporary disruptions across SAST, SCA, CCA, and Secret repository scans and push events. The issue was caused by a surge in reachability scanner jobs that overwhelmed the processing queue, compounded by scanner pods requesting excessive CPU and memory, infrastructure resource limits being reached, and inefficiencies in job prioritization and retry logic. As a result, processing capacity was improperly consumed and a large job backlog accumulated. A series of corrective updates were deployed to stabilize the environment, and the processing environment has since returned to expected performance levels. **Impact** Customers experienced delays for SAST, SCA, CCA, and Secret repository scans and push events, with some requests delayed by several hours and a peak queue size of over 64,000 jobs. Lower priority scans such as Trivy, Syft, and CCA were most affected, though high-priority jobs were eventually processed without further delay. **Key Timeline (IDT)** • **21.06.2026, 17:16 IDT**: A surge in reachability scanner jobs caused the CycodeX queue to grow rapidly. • **22.06.2026, 10:07 IDT**: The issue was identified by an on-call engineer. • **22.06.2026, 12:55 IDT**: We increased the scanning platform resources to process more jobs. • **22.06.2026, 14:10 IDT**: A fix that lowered new reachability scanners was deployed to production. • **22.06.2026, 18:43 IDT**: Existing reachability scanners' priority was lowered. • **23.06.2026, 09:12 IDT**: Scans with higher priority were processed. Only lower priority scans remained, including CCA. • **23.06.2026, 13:51 IDT**: A fix that reduced communication overload to Kubernetes was deployed. The scanning platform started processing scan jobs much faster. • **23.06.2026, 17:34 IDT**: The queue was fully processed. **Root Cause** The issue was triggered by a combination of factors: 1. **Reachability scanner job surge** -- A surge in reachability scanner jobs caused the CycodeX queue to grow rapidly, which led to resource bottlenecks in the cluster and a peak queue size of over 64,000 jobs. 2. **Excessive pod resource requests** -- Due to configuration bugs, scanner pods requested excessive CPU and memory, which prevented efficient scheduling and amplified the resource bottlenecks in the cluster. 3. **Infrastructure resource limits** -- AWS VPC subnet IP and EKS API limits were reached, restricting the cluster's ability to scale and schedule new work. 4. **Job prioritization and retry inefficiencies** -- Inefficiencies in job prioritization and retry logic meant lower priority scans (Trivy, Syft, CCA) competed for capacity and were most affected, while the backlog continued to grow. **Actions Taken** • Increased cluster and node pool capacity. • Fixed job prioritization to deprioritize reachability scans. • Capped resource requests for scanner pods to enable efficient scheduling. • Deployed additional fixes to the scanning platform. • Opened AWS support tickets to address resource limits. • Restored monitoring and logging. • Cleared the job backlog; the queue now processes new jobs as they arrive. **Action Items** • Improve monitoring to better understand the behavior of the processing environment. • Improve scanning optimization and prioritization for all scan types.
**Problem**: SAST (Static Application Security Testing) scans for pull requests were running slowly **Impact**: Some users experienced slow pull request scans potentially delaying code reviews and deployments.
The issue was resolved. The system is fully stable now