46 Cycode incidents · February 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
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
Customers may experience degraded performance in scans. Pull request and CLI scans may be affected.
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.
System should be back to being fully operational.
**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.
Estamos investigando un problema que hace que los acontecimientos más antiguos sean reprocesados. **Impact:** Algunos flujos de trabajo pueden funcionar de nuevo, lo que podría dar lugar a alertas duplicadas. Los escaneos de PR también pueden retrasarse.
Hemos resuelto el atraso de procesamiento causado por un problema durante una migración de Kafka. La cuestión se tradujo en que los acontecimientos más antiguos se tramitaban junto con los nuevos acontecimientos, que causaban retrasos y podían haber actualizado algunas violaciones con un estado obsoleto. Se ha restaurado el procesamiento normal. Sin embargo, los clientes pueden todavía ver algunas violaciones con un estatus obsoleto mientras identificamos y corrigimos los registros afectados. No se retrasaron ni reprocesaron los escaneos de las relaciones públicas, y los flujos de trabajo no se vieron afectados. Seguimos remediando y vigilando de cerca el sistema.
El procesamiento normal ha sido restaurado, y el incidente está ahora en vigilancia. Un pequeño número de clientes todavía puede ver un número limitado de violaciones con un estado anticuado como resultado del incidente. Hemos identificado los entornos potencialmente afectados y estamos trabajando para corregir los registros impactados.
El sistema está plenamente operativo. Un pequeño número de clientes todavía puede ver un número limitado de violaciones con un estado anticuado como resultado del incidente. Hemos identificado los entornos potencialmente afectados y estamos trabajando para corregir los registros impactados.
The platform is now fully operational and processing normally
Traducido automáticamente desde la actualización oficial del incidente.
El equipo identificó un problema con rendimiento degradado con escaneo. Puede haber demoras en iniciar, correr y completar los escaneos. Todos los tipos de escaneo pueden verse afectados (Pulgar solicitud y escáneres CLI también). El equipo ha identificado una cuestión con un mal funcionamiento en el despliegue, y la cuestión debe resolverse en breve.
El equipo ha identificado la causa raíz y la ha resuelto. Estamos viendo el sistema volviendo a la estabilidad.
El sistema ha vuelto a estar plenamente operativo.
*Causa real* The incident was caused by a deployment of one service that ran a database migration. El equipo ha identificado que esta migración contenía código defectuoso y, como resultado, dio lugar a la sobrecarga de bases de datos al intentar desplegar el servicio. Como resultado, el servicio se redujo parcialmente hasta que se revertió el despliegue. Durante este tiempo, todos los escaneos fueron procesados con menor rendimiento de lo esperado.
Traducido automáticamente desde la actualización oficial del incidente.
Componente GitHub: Solicitudes de API Original GitHub incident: https://stspg.io/vr201n49yl53
Componente GitHub: Solicitudes de API Original GitHub incident: https://stspg.io/vr201n49yl53
Traducido automáticamente desde la actualización oficial del incidente.
Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/sm1tp7kfm4vj
Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/sm1tp7kfm4vj
Componente GitHub: Pull Solicita Original GitHub incident: https://stspg.io/sm1tp7kfm4vj
Traducido automáticamente desde la actualización oficial del incidente.
Hemos notado un rendimiento degradado en IaC Pull Request scans. Estamos discutiendo el problema.
Hemos identificado la causa raíz de las lentitudes y estamos poniendo contramedidas en su lugar.
El lag que condujo a la lentitud casi ha terminado. Estamos monitoreando la situación.
La cuestión se ha resuelto y seguimos vigilando la situación.
Traducido automáticamente desde la actualización oficial del incidente.
Componente GitHub: Solicitudes de API, Solicitudes de Pull Original GitHub incident: https://stspg.io/j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Traducido automáticamente desde la actualización oficial del incidente.
Componente GitHub: Webhooks Original GitHub incident: https://stspg.io/syhr80rth84z
Componente GitHub: Webhooks, Pull Solicita Original GitHub incident: https://stspg.io/syhr80rth84z
Componente GitHub: Webhooks, Pull Solicita Original GitHub incident: https://stspg.io/syhr80rth84z
Traducido automáticamente desde la actualización oficial del incidente.
A **1:41** PM EDT, identificamos un problema que causa tasas de error elevadas durante el procesamiento de solicitudes en la Plataforma UI. La cuestión se mitigó rápidamente y la plataforma está funcionando normalmente. Nuestro equipo sigue monitoreando activamente la plataforma para garantizar la estabilidad de los servicios.
El incidente se ha resuelto y la plataforma funciona normalmente.
Traducido automáticamente desde la actualización oficial del incidente.
Hemos notado una porción de CLI Secrets escaneando. Estamos recortando activamente el problema.
Hemos identificado que la versión 3.17.1 de CLI introdujo el comportamiento defectuoso. Degrading the CLI version to 3.17.0 should temporary resolve the issue while we continue to understand and resolve the root cause.
Se ha aplicado una solución y se restablece plenamente la funcionalidad; seguimos monitoreando para asegurar que todo permanezca estable.
Traducido automáticamente desde la actualización oficial del incidente.
Debido al aumento de las cargas de escaneo, observamos retrasos en las actualizaciones de estado de violación que incluyen la auto-resolución de las violaciones. La fuente del aumento repentino ha sido mitigada y el retraso ya está disminuyendo. Seguiremos monitoreando la situación hasta que volvamos a la normalidad
Seguimos monitoreando el procesamiento de detección y los retrasos asociados en las actualizaciones del estado de violación (incluida la auto-resolución)
Traducido automáticamente desde la actualización oficial del incidente.
Hemos notado un rendimiento degradado en múltiples componentes del sistema. Estamos identificando todos los componentes afectados e identificando la causa raíz.
Hemos notado el rendimiento degradado en múltiples componentes de la aplicación UI. Los escaneos, así como la Solicitud de Tiro y los escaneos CLI también pueden verse afectados.
Estamos observando tasas elevadas de tiempo de Redis. Estamos escalando la capacidad de agrupación de Redis para mitigar el impacto y restaurar el rendimiento de servicio estable
La región se ha recuperado y está operando normalmente. Estamos monitoreando de cerca el desempeño del sistema para garantizar una estabilidad continua
El sistema está en pleno funcionamiento. No debería haber más rendimiento degradado. **Summary** Se observó un período de desaceleración e intervalos intermitentes que afectaban a diversas funciones del sistema en la región de la UE, incluyendo la interfaz de aplicación y los escaneos de solicitud (PR). La cuestión fue causada principalmente por un sistema de procesamiento que alcanzaba sus límites de capacidad de red y memoria, exacerbado por un alto volumen de actividad automatizada de una sola fuente. Desde entonces hemos mejorado la infraestructura subyacente y aplicado salvaguardias para evitar que una actividad similar de alto volumen impacte al sistema. La cuestión se resuelve plenamente y todos los servicios han regresado a los niveles de rendimiento previstos. **Key Timeline (IDT)** ** 13 de julio de 2026, 11:44 IDT**: Incident detectado después de informes de retrasos en la IU y de exploración de PR. ** 13 de julio de 2026, 12:19 IDT**: Botella de infraestructura identificada; decisión to upgrade the processing cluster. ** 13 de julio de 2026, 12:26 IDT**: Se identificó un proceso automatizado de alto volumen y se disolvió para reducir la carga inmediata. ** 13 de julio de 2026, 13:09 IDT**: Mejora de infraestructura completada; rendimiento de red devuelto a niveles normales. ** 13 de julio de 2026, 15:35 IDT**: Todos los atrasos se retiraron, y el incidente fue resuelto oficialmente. *Causa real* El incidente fue desencadenado por una combinación de factores: un grupo de procesamiento alcanzó su máximo ancho de banda de red y capacidad de memoria debido a una configuración insuficiente para el volumen de trabajo actual. This was further tened by a specific automatic workflow that generated an inusually high volume of update requests. Además, una diferencia de configuración en el oleoducto de procesamiento de mensajes en la región de la UE impidió que el sistema manejara eficazmente el atraso resultante. ** Acciones tomadas** • Infraestructura actualizada**: El grupo de procesamiento fue actualizado a un tipo de instancia de mayor capacidad para proporcionar más ancho de banda de red y memoria. • Fuente de alto volumen desactivado**: Un identificador específico del cliente responsable del tráfico excesivo fue desactivado temporalmente para restaurar la estabilidad del sistema. **Conectividad restaurada**: Se reiniciaron los componentes de servicio afectados para garantizar que restablecieron conexiones limpias a la infraestructura actualizada. • Paralelismo de procesamiento creciente**: El número de particiones en la cola de mensajes afectados se incrementó para permitir que el sistema procesara el atraso más rápidamente. ** Temas de acción** • ** Vigilancia de Mejoras**: Implementar nuevas alertas para la utilización de la red y la memoria para detectar problemas de capacidad antes de que impacten a los clientes. • **Optimize Update Workflow**: Refactorizar el proceso de actualización de estado a las solicitudes de lotes, reduciendo significativamente la carga en el sistema de procesamiento. • **Implement Rate Limiting**: Introducir salvaguardias para evitar que cualquier fuente consuma recursos desproporcionados del sistema. • **Standardize Regional Configurations**: Realizar una auditoría para asegurar que la configuración de la infraestructura y la cola de mensajes sea coherente en todas las regiones.
Traducido automáticamente desde la actualización oficial del incidente.
Hemos identificado un problema que puede causar **inexactitudes de violación** en ** algunos paneles de productos** y paneles de panel personalizados que dependen de datos de violación (no todos los tableros de control están afectados). Ya hemos comenzado el trabajo correctivo, pero tomará tiempo para completarlo completamente, y puede ver que los recuentos cambian a medida que se corrige la información. Compartiremos otra actualización una vez que la solución haya terminado de funcionar y la exactitud de los datos está completamente restaurada.
Hemos logrado avances significativos en la corrección de los inexactos cargos de violación que afectan a algunos productos y paneles personalizados. • **Estado actual:** La solución ha completado con éxito la gran mayoría de las cuentas, y se ha restaurado la exactitud de los datos. • **Siguientes pasos:** Estamos resolviendo activamente la cuestión del pequeño número de cuentas afectadas restantes.
La funcionalidad está totalmente restaurada; seguimos monitoreando para asegurar que todo permanezca estable.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando un problema que afecta a los servicios de Explorabilidad de Riesgo Maestro, Remediación de Riesgo AI, Remediación Maestro y Graph AI.
Identificamos un problema de configuración de firewall que impactaba los servicios de Maestro AI. La configuración se ha actualizado y los servicios afectados se han recuperado. Seguimos vigilando la situación y estamos trabajando en una mayor estabilización. Algunos resultados degradados todavía pueden ser observados mientras completamos mejoras adicionales.
Se ha resuelto la cuestión que afecta a los servicios de Maestro AI. Explorabilidad de Riesgo Maestro, Remediación de Riesgo AI, Remediación Maestro y Graph AI están disponibles y operan normalmente. **Summary** El 9 de julio de 2026, los clientes que utilizaron el servicio Maestro en el entorno de producción europeo experimentaron un período de servicio indisponible. El problema comenzó tras una actualización de configuración que cambió inadvertidamente la ruta regional del servicio. Esto causó que el sistema intentara las conexiones a través de una vía de red que carecía de los permisos necesarios y a una región donde no se disponía de modelos específicos de procesamiento. La cuestión se ha resuelto totalmente y se ha restaurado el servicio a todos los clientes afectados. **Key Timeline (IDT)** • ** 9 de julio de 2026, 12:02 IDT:** The incident was identified and an investigation was initiated. • ** 9 de julio de 2026, 12:07 IDT:** Se emitió notificación pública sobre la interrupción del servicio. • ** 9 de julio de 2026, 13:00 IDT:** Se aplicó una configuración de red, restaurando la conectividad primaria. • ** 9 de julio de 2026, 13:39 IDT:** El servicio se restableció totalmente después de la aplicación de los modelos de retrocesos, y el incidente fue marcado como resuelto. *Causa real* La interrupción del servicio fue activada por una actualización reciente al proceso de autenticación y configuración. Esta actualización introdujo un conflicto en la forma en que el sistema identificó su región operativa. Específicamente, un proceso de actualización automatizado superó la configuración manual, enrollando el tráfico a un punto final regional diferente. Este nuevo camino fue bloqueado por una norma de seguridad de la red desaparecida e intentó utilizar un modelo de procesamiento que no fue apoyado en esa región específica, lo que llevó a la falla de servicio. ** Acciones tomadas** • **Restored Network Connectivity:** Reglas de seguridad de red actualizadas manualmente para permitir el tráfico seguro a través del nuevo punto final regional. • **Modelos ampliados:** Configured the system to use alternative processing models to ensure immediate service availability while long-term regional configuraciones were adjusted. • ** Comunicaciones de estado actualizadas:** Mantener actualizaciones en tiempo real para los interesados y clientes durante todo el proceso de recuperación. ** Temas de acción** • **Standardize Configuration Precedence:** Actualizar el flujo de trabajo de despliegue para evitar que los procesos automatizados se anulen silenciosamente en entornos críticos. • ** Auditoría de la infraestructura:** Realizar un examen amplio de las normas de seguridad de la red en todas las regiones para garantizar la coherencia y prevenir deficiencias de conectividad similares. • ** Mejorar el monitoreo automatizado:** Implementar controles de salud de extremo a extremo y sondas sintéticas para detectar problemas de conectividad regional automáticamente antes de que impacten a los usuarios. • **Mejorar Políticas de Despliegue:** Establecer nuevas directrices para asegurar que los cambios de configuración se implementen y validen en entornos de producción con mayor frecuencia para reducir el riesgo de actualizaciones de "stale".
Traducido automáticamente desde la actualización oficial del incidente.
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.
**Investigación - Problemas con las violaciones y los tableros de mando personalizados (Prod-US)** Actualmente estamos investigando un problema en nuestro entorno **Prod-US** donde las violaciones no se cargan. Como resultado, los paneles de panel personalizados que confían en datos de violación también pueden no presentar o mostrar errores. Nuestro equipo de ingeniería está buscando activamente la causa raíz, y proporcionaremos actualizaciones aquí mientras aprendemos más. Nos disculpamos por la molestia.
Se ha implementado una solución para los problemas que afectan las violaciones y los paneles personalizados en Prod-US. Estamos monitoreando activamente el medio ambiente para garantizar que se restablezcan plenamente los servicios.
Se ha resuelto el problema central, y las violaciones y los tableros de mando personalizados deberían estar funcionando como normales. Nuestro equipo está monitoreando activamente la sincronización de datos para resolver cualquier discrepancia restante con nuevas violaciones. Proporcionaremos una actualización final una vez que la sincronización esté completa.
Continuamos monitoreando el proceso de sincronización de datos para nuevas violaciones en la UI. Aunque se ha restaurado la funcionalidad, puede tardar hasta **6 horas** para que todos los datos recientes puedan ponerse al día y reflejar con precisión. Proporcionaremos una actualización final una vez que la sincronización esté completa.
La sincronización de datos está completa, y todas las violaciones recientes han poblado exitosamente en la UI. Las violaciones y los tableros de mando personalizados funcionan normalmente, y el incidente está completamente resuelto. Apreciamos su paciencia mientras trabajamos para restaurar el servicio completo.
La funcionalidad está totalmente restaurada; seguimos monitoreando para asegurar que todo permanezca estable.
Traducido automáticamente desde la actualización oficial del incidente.
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