46 Cycode incidents · Cʼhwevrer 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
Traduzido automaticamente da atualização oficial do incidente.
Os clientes podem experimentar desempenho degradado em varreduras. Faça o pedido e os exames CLI podem ser afetados.
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.
Traduzido automaticamente da atualização oficial do incidente.
Estamos investigando uma questão que faz com que eventos mais antigos sejam reprocessados. **Impacto:** Alguns fluxos de trabalho podem ser executados novamente, o que pode resultar em alertas duplicados. Os exames de RP também podem ser atrasados.
Resolvemos o atraso de processamento causado por um problema durante uma migração Kafka. A questão resultou em eventos mais antigos sendo processados ao lado de novos eventos, o que causou atrasos e pode ter atualizado algumas violações com um status ultrapassado. O processamento normal foi restaurado. No entanto, os clientes ainda podem ver algumas violações com um status desatualizado enquanto identificamos e corrigimos os registros afetados. Os exames de RP não foram atrasados ou reprocessados, e os fluxos de trabalho não foram afetados. Continuamos a remediar e a acompanhar de perto o sistema.
O processamento normal foi restaurado e o incidente está agora a ser monitorizado. Um pequeno número de clientes ainda pode ver um número limitado de violações com um status ultrapassado como resultado do incidente. Identificamos os ambientes potencialmente afetados e estamos trabalhando para corrigir os registros impactados.
O sistema está totalmente operacional. Um pequeno número de clientes ainda pode ver um número limitado de violações com um status ultrapassado como resultado do incidente. Identificamos os ambientes potencialmente afetados e estamos trabalhando para corrigir os registros impactados.
The platform is now fully operational and processing normally
Traduzido automaticamente da atualização oficial do incidente.
A equipe identificou um problema com desempenho degradado com a digitalização. Pode haver atrasos no início, execução e conclusão dos exames. Todos os tipos de varredura podem ser afetados (requisito de preenchimento e CLI também). A equipe identificou um problema com uma falha na implantação, e o problema deve ser resolvido em breve.
A equipa identificou a causa principal e resolveu-a. Estamos vendo o sistema voltar à estabilidade.
O sistema voltou a ser totalmente operacional.
**Root Cause** O incidente foi causado por uma implantação de um serviço que executou uma migração de banco de dados. A equipe identificou que essa migração continha código defeituoso e, como resultado, leva à sobrecarga do banco de dados ao tentar implantar o serviço. Como resultado, o serviço foi parcialmente reduzido até que a implantação foi revertida. Durante esse período, todos os exames foram processados com desempenho inferior ao esperado.
Traduzido automaticamente da atualização oficial do incidente.
Componente GitHub: Pedidos de API Incidente GitHub original: https://stspg.io/vr201n49yl53
Componente GitHub: Pedidos de API Incidente GitHub original: https://stspg.io/vr201n49yl53
Traduzido automaticamente da atualização oficial do incidente.
Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/sm1tp7kfm4vj
Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/sm1tp7kfm4vj
Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/sm1tp7kfm4vj
Traduzido automaticamente da atualização oficial do incidente.
Notamos desempenho degradado em exames IaC Pull Request. Estamos a resolver o problema.
Identificámos a causa raiz das lentidãos e estamos a pôr em prática contramedidas.
O atraso que levou à lentidão está quase no fim. Estamos a acompanhar a situação.
A questão foi resolvida e continuamos a acompanhar a situação.
Traduzido automaticamente da atualização oficial do incidente.
Componente GitHub: Pedidos de API, Pedidos de Puxe Incidente GitHub original: https://stspg.io/j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Traduzido automaticamente da atualização oficial do incidente.
Componente GitHub: Webhooks Incidente GitHub original: https://stspg.io/syhr80rth84z
Componente GitHub: Webhooks, Puxe Pedidos Incidente GitHub original: https://stspg.io/syhr80rth84z
Componente GitHub: Webhooks, Puxe Pedidos Incidente GitHub original: https://stspg.io/syhr80rth84z
Traduzido automaticamente da atualização oficial do incidente.
Em **1:41** PM EDT, identificamos um problema causando taxas de erro elevadas durante o processamento de requisição na interface de plataforma. O problema foi mitigado prontamente, e a plataforma está atualmente operando normalmente. Nossa equipe continua monitorando ativamente a plataforma para garantir a estabilidade do serviço.
O incidente foi resolvido e a plataforma está a funcionar normalmente.
Traduzido automaticamente da atualização oficial do incidente.
Reparamos que uma parte dos exames de CLI Secrets estão a falhar. Estamos a analisar activamente o problema.
Identificamos que a CLI versão 3.17.1 introduziu o comportamento defeituoso. Degradar a versão CLI para 3.17.0 deve resolver temporariamente o problema enquanto continuamos a entender e resolver a causa raiz.
Uma correção foi aplicada e a funcionalidade é totalmente restaurada; continuamos a monitorar para garantir que tudo permaneça estável.
Traduzido automaticamente da atualização oficial do incidente.
Devido ao aumento das cargas de varredura, observamos atrasos nas atualizações de status de violação que incluem resolução automática de violações. A fonte do aumento súbito foi atenuada e o atraso já está diminuindo. Vamos continuar a monitorizar a situação até voltarmos ao normal
Continuamos a monitorar o processamento de detecção e os atrasos associados em atualizações de status de violação (incluindo resolução automática)
Traduzido automaticamente da atualização oficial do incidente.
Notamos desempenho degradado em múltiplos componentes do sistema. Estamos identificando todos os componentes afetados e identificando a causa raiz.
Notamos desempenho degradado em múltiplos componentes da interface de aplicação. Escaneamentos, bem como Pull Request e CLI também podem ser afetados.
Estamos observando altas taxas de tempo limite de Redis. Estamos escalando capacidade de cluster Redis para mitigar o impacto e restaurar o desempenho estável do serviço
A região recuperou e está a funcionar normalmente. Estamos acompanhando de perto o desempenho do sistema para garantir a estabilidade contínua
O sistema está agora totalmente operacional. Não deve haver mais desempenho degradado. **Resumo** Observamos um período de lentidão e intervalos intermitentes que afetam várias funções do sistema na região da UE, incluindo a interface de aplicação e os exames de solicitação de tração (RP). A questão foi causada principalmente por um sistema de processamento que atingiu seus limites de rede e capacidade de memória, exacerbado por um alto volume de atividade automatizada de uma única fonte. Desde então, actualizámos a infra-estrutura subjacente e implementámos salvaguardas para evitar que uma actividade semelhante de alto volume afectasse o sistema. A questão está agora totalmente resolvida, e todos os serviços voltaram aos níveis de desempenho esperados. ** Linha temporal chave (IDT) • ** 13 de Julho de 2026, 11:44 IDT**: Incidente detectado após relatos de lentidão da IU e atraso no exame de RP. • ** 13 de Julho de 2026, 12:19 TDT**: Gargalo de infraestrutura identificado; decisão tomada para atualizar o cluster de processamento. • ** 13 de Julho de 2026, 12:26 TDI**: Um processo automatizado de alto volume foi identificado e desativado para reduzir a carga imediata. • ** 13 de Julho de 2026, 13:09 DDT**: A actualização da infra- estrutura foi concluída; o rendimento da rede voltou aos níveis normais. • ** 13 de Julho de 2026, 15:35 IDT**: Todos os atrasos foram resolvidos, e o incidente foi oficialmente resolvido. **Root Cause** O incidente foi desencadeado por uma combinação de fatores: um cluster de processamento atingiu sua máxima largura de banda de rede e capacidade de memória devido a uma configuração subdimensionada para a carga de trabalho atual. Isto foi ainda mais tenso por um fluxo de trabalho automatizado específico que gerou um volume anormalmente alto de solicitações de atualização. Além disso, uma diferença de configuração no gasoduto de processamento de mensagens na região da UE impediu o sistema de lidar eficazmente com o atraso resultante. **Acções tomadas ** • **Infra-estrutura actualizada**: O cluster de processamento foi atualizado para um tipo de instância de maior capacidade para fornecer mais largura de banda de rede e memória. • **High-Volume desactivado Fonte**: Um identificador específico do cliente responsável pelo tráfego excessivo foi temporariamente desativado para restaurar a estabilidade do sistema. • ** Conectividade restaurada**: Componentes de serviço afetados foram reiniciados para garantir que eles restabelecessem conexões limpas para a infraestrutura atualizada. • ** Aumento do Paralelismo de Processamento **: O número de partições na fila de mensagens afetadas foi aumentado para permitir que o sistema processasse o backlog mais rapidamente. ** Itens de Acção ** • **Enhance Monitoring**: Implemente novos alertas para utilização de rede e memória para detectar problemas de capacidade antes de impactar os clientes. • ** Otimizar fluxo de trabalho de atualização**: Refaça o processo de atualização de status para pedidos em lote, reduzindo significativamente a carga no sistema de processamento. • **Limitação da Taxa de Implementação**: Introduzir salvaguardas para evitar que uma única fonte consuma recursos desproporcionados. • ** normalizar as configurações regionais**: Realize uma auditoria para garantir que as configurações de infraestrutura e fila de mensagens sejam consistentes em todas as regiões.
Traduzido automaticamente da atualização oficial do incidente.
Identificamos um problema que pode causar ** contagens de violação inexatas** em ** alguns painéis de produtos e painéis de painel personalizados que dependem de dados de violação (nem todos os painéis são afetados). Nós já começamos o trabalho corretivo, mas levará tempo para completar completamente, e você pode ver as contagens mudarem à medida que os dados são corrigidos. Vamos compartilhar outra atualização uma vez que a correção terminou a execução e a precisão de dados é totalmente restaurada.
Fizemos progressos significativos na correção das contagens de violação imprecisas que afetam alguns painéis de produtos e personalizados. • ** Estado actual: ** A correção foi concluída com sucesso para a grande maioria das contas, e a precisão completa dos dados foi restaurada. • ** Passos seguintes: ** Estamos a resolver activamente a questão do pequeno número de contas ainda afectadas.
A funcionalidade é totalmente restaurada; continuamos a monitorar para garantir que tudo permaneça estável.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos investigando uma questão que afeta a Explorabilidade de Risco Maestro, Remediação de IA de Risco, Remediação Maestro e serviços de IA Graph.
Identificamos um problema de configuração de firewall que estava impactando os serviços de IA Maestro. A configuração foi atualizada e os serviços afetados se recuperaram. Continuamos a acompanhar a situação e a trabalhar numa maior estabilização. Algum desempenho degradado ainda pode ser observado enquanto completamos melhorias adicionais.
A questão que afecta os serviços do Maestro IA foi resolvida. Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation e Graph AI estão agora disponíveis e operando normalmente. **Resumo** Em 9 de julho de 2026, os clientes que utilizavam o serviço Maestro no ambiente europeu de produção experimentaram um período de indisponibilidade de serviço. O problema começou após uma atualização de configuração que inadvertidamente mudou o roteamento regional do serviço. Isso fez com que o sistema tentasse conexões através de um caminho de rede que carecesse das permissões necessárias e para uma região onde modelos de processamento específicos não estivessem disponíveis. A questão foi totalmente resolvida, e o serviço foi restaurado para todos os clientes afetados. ** Linha temporal chave (IDT) ** 9 de Julho de 2026, 12:02 O incidente foi identificado e uma investigação foi iniciada. • ** 9 de julho de 2026, 12:07 TDI:** Notificação pública sobre a interrupção do serviço. • ** 9 de Julho de 2026, 13:00 DDT: ** Foi aplicada uma correção de configuração de rede, restaurando a conectividade primária. ** 9 de Julho de 2026, 13:39 O serviço foi totalmente restaurado após a implementação de retrocessos do modelo, e o incidente foi marcado como resolvido. **Root Cause** A interrupção do serviço foi desencadeada por uma atualização recente do processo de autenticação e configuração. Esta atualização introduziu um conflito na forma como o sistema identificou sua região operacional. Especificamente, um processo de atualização automatizado overrode configurações manuais, direcionando tráfego para um endpoint regional diferente. Este novo caminho foi bloqueado por uma regra de segurança de rede em falta e tentou usar um modelo de processamento que não foi suportado nessa região específica, levando à falha do serviço. **Acções tomadas ** • Conectividade de rede restaurada:** Regras de segurança de rede atualizadas manualmente para permitir o tráfego seguro através do novo endpoint regional. • **Recursos do modelo implementados: ** Configurou o sistema para usar modelos de processamento alternativos para garantir disponibilidade imediata de serviços, enquanto configurações regionais de longo prazo foram ajustadas. • ** Comunicações de Estado actualizadas: ** Manteve atualizações em tempo real para stakeholders e clientes durante todo o processo de recuperação. ** Itens de Acção ** • **Precedência de Configuração de Padrão: ** Atualize o fluxo de trabalho de implantação para evitar que processos automatizados sobreponham silenciosamente as configurações críticas do ambiente. • ** Auditoria das infra-estruturas: ** Realize uma revisão abrangente das regras de segurança da rede em todas as regiões para garantir a coerência e evitar lacunas de conectividade semelhantes. • ** Melhor monitorização automatizada: ** Implementar verificações de saúde de ponta a ponta e sondas sintéticas para detectar problemas de conectividade regional automaticamente antes de impactar os usuários. • **Melhorar as políticas de implantação: ** Estabelecer novas diretrizes para garantir que as mudanças de configuração sejam implantadas e validadas em ambientes de produção com maior frequência para reduzir o risco de atualizações "stale".
Traduzido automaticamente da atualização oficial do 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.
**Investigação - Problemas com Violações e Painéis Personalizados (Prod-US) ** Atualmente estamos investigando um problema em nosso ambiente **Prod-US** onde violações estão falhando em carregar. Como resultado, painéis de painel personalizados que dependem de dados de violação também podem falhar em renderizar ou exibir erros. Nossa equipe de engenharia está olhando ativamente para a causa raiz, e nós forneceremos atualizações aqui como aprendemos mais. Pedimos desculpa pelo inconveniente.
Uma correção foi implantada para os problemas que afetam violações e painéis personalizados em Prod-US. Estamos a monitorizar activamente o ambiente para garantir que os serviços sejam totalmente restaurados.
O problema principal foi resolvido, e violações e painéis personalizados devem agora estar funcionando como normal. Nossa equipe está monitorando ativamente a sincronização de dados para resolver quaisquer discrepâncias remanescentes com novas violações. Forneceremos uma atualização final assim que a sincronização estiver completa.
Continuamos a monitorar o processo de sincronização de dados para novas violações na UI. Embora a funcionalidade tenha sido restaurada, pode levar até **6 horas** para que todos os dados recentes alcancem e reflitam com precisão. Nós forneceremos uma atualização final assim que a sincronização estiver completa.
A sincronização de dados está completa, e todas as violações recentes têm povoado com sucesso na UI. Violações e painéis personalizados estão funcionando normalmente, e o incidente está totalmente resolvido. Agradecemos a sua paciência enquanto trabalhávamos para restaurar o serviço completo.
A funcionalidade é totalmente restaurada; continuamos a monitorar para garantir que tudo permaneça estável.
Traduzido automaticamente da atualização oficial do 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