46 Cycode incidents · febbraio 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
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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.
Stiamo indagando su un problema che causa la rielaborazione di eventi più vecchi. # Impatto # Alcuni flussi di lavoro possono funzionare di nuovo, che potrebbe portare a avvisi duplicati. Le scansioni di PR possono anche essere ritardate.
Abbiamo risolto il backlog di elaborazione causato da un problema durante una migrazione Kafka. Il problema ha portato a nuovi eventi, che hanno causato ritardi e potrebbero aver aggiornato alcune violazioni con uno stato obsoleto. La lavorazione normale è stata ripristinata. Tuttavia, i clienti possono ancora vedere alcune violazioni con uno stato obsoleto mentre identifichiamo e correggiamo i record interessati. Le scansioni PR non sono state ritardate o ritrattate, e i flussi di lavoro non sono stati colpiti. Stiamo continuando la bonifica e monitoriamo attentamente il sistema.
L'elaborazione normale è stata ripristinata, e l'incidente è ora in monitoraggio. Un piccolo numero di clienti può ancora vedere un numero limitato di violazioni con uno stato obsoleto a seguito dell'incidente. Abbiamo identificato gli ambienti potenzialmente interessati e stiamo lavorando per correggere i record colpiti.
Il sistema è completamente operativo. Un piccolo numero di clienti può ancora vedere un numero limitato di violazioni con uno stato obsoleto a seguito dell'incidente. Abbiamo identificato gli ambienti potenzialmente interessati e stiamo lavorando per correggere i record colpiti.
The platform is now fully operational and processing normally
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Il team ha identificato un problema con prestazioni degradate con la scansione. Ci possono essere ritardi nell'avvio, nell'esecuzione e nel completamento delle scansioni. Tutti i tipi di scansione possono essere influenzati (chiesta Pull e scansioni CLI pure). Il team ha identificato un problema con un malfunzionamento nella distribuzione, e il problema dovrebbe essere risolto a breve.
Il team ha identificato la causa principale e risolto. Stiamo vedendo il sistema tornare alla stabilità.
Il sistema è ora tornato ad essere pienamente operativo.
♪Root Cause ♪ L'incidente è stato causato da una distribuzione di un servizio che ha eseguito una migrazione di database. Il team ha identificato che questa migrazione conteneva codice difettoso e, di conseguenza, portare a sovraccarico database quando si tenta di distribuire il servizio. Di conseguenza, il servizio è stato parzialmente disattivato fino a quando il dispiegamento è stato ripristinato. Durante questo periodo, tutte le scansioni sono state elaborate con prestazioni inferiori al previsto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Componente GitHub: Richieste API Incidente GitHub originale: https://stspg.io/vr201n49yl53
Componente GitHub: Richieste API Incidente GitHub originale: https://stspg.io/vr201n49yl53
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Componente GitHub: Pull Requests Incidente GitHub originale: https://stspg.io/sm1tp7kfm4vj
Componente GitHub: Pull Requests Incidente GitHub originale: https://stspg.io/sm1tp7kfm4vj
Componente GitHub: Pull Requests Incidente GitHub originale: https://stspg.io/sm1tp7kfm4vj
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Abbiamo notato le prestazioni degradate in IaC Pull Request scansioni. Stiamo risolvendo il problema.
Abbiamo identificato la causa principale delle lentezze e stiamo mettendo contromisure in atto.
Il ritardo che ha portato a lentezze è quasi finito. Stiamo monitorando la situazione.
La questione è stata risolta e continuiamo a monitorare la situazione.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Componente GitHub: Richieste API, Pull Requests Incidente GitHub originale: https://stspg.io/j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Componente GitHub: Webhooks Incidente GitHub originale: https://stspg.io/syhr80rth84z
Componente GitHub: Webhooks, Pull Requests Incidente GitHub originale: https://stspg.io/syhr80rth84z
Componente GitHub: Webhooks, Pull Requests Incidente GitHub originale: https://stspg.io/syhr80rth84z
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
A **1:41** PM EDT, abbiamo identificato un problema causando elevati tassi di errore durante l'elaborazione delle richieste nell'interfaccia utente della piattaforma. Il problema è stato mitigato tempestivamente, e la piattaforma è attualmente in funzione normalmente. Il nostro team continua a monitorare attivamente la piattaforma per garantire la stabilità dei servizi.
L'incidente è stato risolto e la piattaforma funziona normalmente.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Abbiamo notato una parte di CLI Secrets che non riesce. Stiamo attivamente triagendo il problema.
Abbiamo identificato che la versione CLI 3.17.1 ha introdotto il comportamento difettoso. Degradare la versione CLI a 3.17.0 dovrebbe temporaneamente risolvere il problema mentre continuiamo a capire e risolvere la causa principale.
Una correzione è stata applicata e la funzionalità è completamente restaurata; continuiamo a monitorare per garantire che tutto rimanga stabile.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
A causa di carichi di scansione aumentati, abbiamo osservato ritardi negli aggiornamenti di stato di violazione che include la risoluzione automatica delle violazioni. La fonte dell'improvviso aumento è stata mitigata e il ritardo sta già diminuendo. Continueremo a monitorare la situazione finché non torneremo alla normalità
Stiamo continuando a monitorare l'elaborazione del rilevamento e i relativi ritardi negli aggiornamenti dello stato di violazione (compresa la risoluzione automatica)
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Abbiamo notato le prestazioni degradate in più componenti di sistema. Stiamo identificando tutti i componenti colpiti e identificando la causa principale.
Abbiamo notato le prestazioni degradate in più componenti dell'applicazione UI. Le scansioni, così come le scansioni Pull Request e CLI possono anche essere influenzate.
Stiamo osservando alti tassi di timeout Redis. Stiamo scalando la capacità del cluster Redis per mitigare l'impatto e ripristinare le prestazioni di servizio stabili
La regione ha recuperato e funziona normalmente. Stiamo monitorando attentamente le prestazioni del sistema per garantire la stabilità continua
Il sistema è ora completamente operativo. Non ci dovrebbero essere più prestazioni degradate. # Sommario # Abbiamo osservato un periodo di lentezza e timeout intermittenti che interessano varie funzioni di sistema nella regione dell'UE, tra cui l'interfaccia di applicazione e le scansioni di richiesta di estrazione (PR). Il problema è stato principalmente causato da un sistema di elaborazione che raggiunge i limiti di rete e capacità di memoria, esacerbato da un elevato volume di attività automatizzata da un'unica fonte. Da allora abbiamo migliorato l'infrastruttura sottostante e implementato salvaguardie per evitare simili attività ad alto volume dall'impatto del sistema. Il problema è ora completamente risolto, e tutti i servizi sono tornati ai livelli di prestazioni attesi. ♪Key Timeline (IDT) ♪ 13 luglio 2026, 11:44 IDT**: Rilevato incidente in seguito a rapporti di lentezza dell'interfaccia utente e ritardi di scansione PR. 13 luglio 2026, 12:19 IDT**: Infrastrutture collo di bottiglia identificato; decisione presa per aggiornare il cluster di elaborazione. 13 luglio 2026, 12:26 IDT**: Un processo automatizzato ad alto volume è stato identificato e disabilitato per ridurre il carico immediato. 13 luglio 2026, 13:09 IDT**: Aggiornamento delle infrastrutture completato; il throughput della rete ritorna ai livelli normali. 13 luglio 2026, 15:35 IDT**: Tutti i registri sono stati chiariti e l'incidente è stato ufficialmente risolto. ♪Root Cause ♪ L'incidente è stato innescato da una combinazione di fattori: un cluster di elaborazione ha raggiunto la sua massima larghezza di banda di rete e capacità di memoria a causa di una configurazione sottodimensionata per il carico di lavoro corrente. Questo è stato ulteriormente teso da uno specifico flusso di lavoro automatizzato che ha generato un volume insolitamente elevato di richieste di aggiornamento. Inoltre, una differenza di configurazione nella pipeline di elaborazione dei messaggi nella regione UE ha impedito al sistema di gestire efficacemente il backlog risultante. # Azioni prese # • ** Infrastrutture aggiornate**: Il cluster di elaborazione è stato aggiornato a un tipo di istanza di capacità superiore per fornire una maggiore larghezza di banda e memoria di rete. • **Disabled High-Volume Source**: un identificativo client specifico responsabile del traffico eccessivo è stato temporaneamente disabilitato per ripristinare la stabilità del sistema. • **Connettività ripristinata**: i componenti di servizio interessati sono stati riavviatiti per garantire che i collegamenti puliti ripristinati all'infrastruttura aggiornata. • ** Parallelismo di elaborazione crescente**: Il numero di partizioni nella coda dei messaggi colpiti è stato aumentato per consentire al sistema di elaborare il backlog più rapidamente. **Action Items** • **Enhance Monitoring**: implementare nuovi avvisi per l'utilizzo della rete e della memoria per rilevare i problemi di capacità prima che colpiscano i clienti. • **Ottimizzare il flusso di lavoro di aggiornamento**: Rifare il processo di aggiornamento dello stato alle richieste batch, riducendo significativamente il carico sul sistema di elaborazione. • **Implement Rate Limiting**: Introdurre salvaguardie per evitare che ogni singola fonte consumi risorse di sistema sproporzionate. • **Standardize Regional Configurations**: Condurre un audit per garantire l'infrastruttura e le impostazioni della coda dei messaggi sono coerenti in tutte le regioni.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Abbiamo identificato un problema che può causare **conti di violazione imprecisi** in **qualcuno** cruscotti prodotto e pannelli dashboard personalizzati che si basano su dati di violazione (non tutti i cruscotti sono interessati). Abbiamo già iniziato il lavoro correttivo, ma ci vorrà del tempo per completare completamente, e si può vedere i conti di cambiamento come i dati sono corretti. Condivideremo un altro aggiornamento una volta che la correzione ha finito l'esecuzione e l'accuratezza dei dati è completamente ripristinata.
Abbiamo fatto progressi significativi nel correggere i conti di violazione imprecisi che interessano alcuni prodotti e dashboard personalizzati. • ** Stato attivo: ** La correzione è stata completata con successo per la maggior parte dei conti, e la piena accuratezza dei dati è stata ripristinata. *Next Steps:** Risolviamo attivamente il problema per il piccolo numero di conti rimasti colpiti.
La funzionalità è completamente restaurata; continuiamo a monitorare per garantire che tutto rimanga stabile.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su un problema che riguarda il Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation e Graph AI servizi.
Abbiamo identificato un problema di configurazione del firewall che ha avuto un impatto sui servizi di Maestro AI. La configurazione è stata aggiornata e i servizi interessati sono stati recuperati. Stiamo continuando a monitorare la situazione e stiamo lavorando ad una ulteriore stabilizzazione. Alcune prestazioni degradate possono ancora essere osservate mentre completiamo ulteriori miglioramenti.
È stato risolto il problema dei servizi Maestro AI. Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation e Graph AI sono ora disponibili e funzionano normalmente. # Sommario # Il 9 luglio 2026 i clienti che utilizzano il servizio Maestro nell'ambiente produttivo europeo hanno sperimentato un periodo di servizio indisponibilità. Il problema è iniziato seguendo un aggiornamento di configurazione che ha cambiato inavvertitamente il routing regionale del servizio. Ciò ha portato il sistema a tentare le connessioni attraverso un percorso di rete che mancava delle autorizzazioni necessarie e ad una regione in cui non erano disponibili modelli di elaborazione specifici. Il problema è stato completamente risolto e il servizio è stato ripristinato a tutti i clienti interessati. ♪Key Timeline (IDT) ♪ ** 9 luglio 2026, 12:02 IDT:** L'incidente è stato identificato e un'indagine è stata avviata. • ** 9 luglio 2026, 12:07 IDT:** La notifica pubblica è stata rilasciata per quanto riguarda l'interruzione del servizio. ** 9 luglio 2026, 13:00 IDT:** È stata applicata una soluzione di configurazione di rete, ripristinando la connettività primaria. ** 9 luglio 2026, 13:39 IDT:** Il servizio è stato completamente restaurato dopo l'attuazione dei modelli fallback, e l'incidente è stato segnato come risolto. ♪Root Cause ♪ L'interruzione del servizio è stata attivata da un recente aggiornamento al processo di autenticazione e configurazione. Questo aggiornamento ha introdotto un conflitto nel modo in cui il sistema ha identificato la sua regione operativa. In particolare, un processo di aggiornamento automatizzato sovrascrive le impostazioni manuali, routing traffico a un altro endpoint regionale. Questo nuovo percorso è stato bloccato da una regola di sicurezza di rete mancante e ha tentato di utilizzare un modello di elaborazione che non è stato supportato in quella specifica regione, portando a guasti di servizio. # Azioni prese # • **Connettività di rete ripristinata:** Regole di sicurezza di rete aggiornate manualmente per consentire il traffico sicuro attraverso il nuovo endpoint regionale. • **Implementato Model Fallbacks:** Configurato il sistema per utilizzare modelli di elaborazione alternativi per garantire la disponibilità immediata del servizio, mentre le configurazioni regionali a lungo termine sono state regolate. • ** Comunicazioni di stato aggiornate:** Aggiornamenti in tempo reale per gli stakeholder e i clienti durante il processo di recupero. **Action Items** • **Standardize Configuration Precedence:** Aggiornare il flusso di lavoro di distribuzione per impedire ai processi automatizzati di sovrascrivere silenziosamente le impostazioni dell'ambiente critico. • ** Audit delle infrastrutture:** Condurre una revisione completa delle regole di sicurezza della rete in tutte le regioni per garantire la coerenza e prevenire lacune di connettività simili. • ** Monitoraggio automatico dell'Enhance:** Implementare controlli sanitari end-to-end e sonde sintetiche per rilevare automaticamente i problemi di connettività regionale prima di influenzare gli utenti. • ** Politiche di distribuzione: ** Stabilire nuove linee guida per garantire che le modifiche di configurazione siano implementate e convalidate in ambienti produttivi più frequentemente per ridurre il rischio di aggiornamenti "stale".
Tradotto automaticamente dall'aggiornamento ufficiale dell'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.
**Investigazione - Problemi con violazioni e Dashboard personalizzati (Prod-US)** Stiamo attualmente indagando su un problema nel nostro ambiente **Prod-US** dove le violazioni non sono in grado di caricare. Di conseguenza, i pannelli di dashboard personalizzati che si basano sui dati di violazione possono anche non rendere o visualizzare errori. Il nostro team di ingegneria sta attivamente cercando nella causa principale, e forniremo aggiornamenti qui come si impara di più. Ci scusiamo per l'inconveniente.
Una correzione è stata implementata per le questioni che riguardano violazioni e dashboard personalizzati in Prod-US. Stiamo monitorando attivamente l'ambiente per garantire che i servizi siano completamente restaurati.
Il problema principale è stato risolto, e le violazioni e dashboard personalizzati dovrebbero ora funzionare come normale. Il nostro team sta monitorando attivamente la sincronizzazione dei dati per risolvere eventuali rimanenti discrepanze con violazioni più recenti. Forniamo un aggiornamento finale una volta che la sincronizzazione è completa.
Stiamo continuando a monitorare il processo di sincronizzazione dei dati per nuove violazioni nell'interfaccia utente. Mentre la funzionalità è stata ripristinata, può richiedere fino a **6 ore** per tutti i dati recenti di recuperare e riflettere con precisione. Forniamo un aggiornamento finale una volta che la sincronizzazione è completa.
La sincronizzazione dei dati è completa, e tutte le recenti violazioni hanno popolato con successo nell'interfaccia utente. Le violazioni e le dashboard personalizzate funzionano normalmente, e l'incidente è completamente risolto. Apprezziamo la vostra pazienza mentre abbiamo lavorato per ripristinare il servizio completo.
La funzionalità è completamente restaurata; continuiamo a monitorare per garantire che tutto rimanga stabile.
Tradotto automaticamente dall'aggiornamento ufficiale dell'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