GitHub incident can affect Cycode
- investigating
GitHub component: Pull Requests Original GitHub incident: https://stspg.io/ssd9z8l2g46v
- resolved
GitHub component: Pull Requests Original GitHub incident: https://stspg.io/ssd9z8l2g46v
46 Cycode incidents · februar 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.
Vi undersøger et problem, der får ældre hændelser til at blive genbehandlet. * * Indvirkning: * * Nogle arbejdsgange kan køre igen, hvilket kan resultere i duplikerede indberetninger. PR scanninger kan også blive forsinket.
Vi har løst den manglende behandling forårsaget af et problem under en Kafka migration. Spørgsmålet resulterede i, at ældre begivenheder blev behandlet sammen med nye begivenheder, hvilket forårsagede forsinkelser og kan have opdateret nogle overtrædelser med en forældet status. Den normale behandling er genoprettet. Men kunderne kan stadig se nogle overtrædelser med en forældet status, mens vi identificere og korrigere de berørte optegnelser. PR-scanninger blev ikke forsinket eller ombehandlet, og arbejdsgange blev ikke påvirket. Vi fortsætter oprensningen og overvåger nøje systemet.
Normal behandling er blevet genoprettet, og hændelsen er nu i overvågning. Et lille antal kunder kan stadig se et begrænset antal overtrædelser med en forældet status som følge af hændelsen. Vi har identificeret de potentielt berørte miljøer og arbejder på at korrigere de ramte poster.
Systemet er fuldt funktionsdygtigt. Et lille antal kunder kan stadig se et begrænset antal overtrædelser med en forældet status som følge af hændelsen. Vi har identificeret de potentielt berørte miljøer og arbejder på at korrigere de ramte poster.
The platform is now fully operational and processing normally
Automatisk oversat fra den officielle hændelsesopdatering.
Holdet identificerede et problem med forringet ydeevne med scanning. Der kan være forsinkelser i at starte, køre og fuldføre scanninger. Alle scanningstyper kan blive påvirket (Træk anmodning og CLI scanner så godt). Holdet har identificeret et problem med en fejl i indsættelsen, og problemet bør løses inden længe.
Holdet har identificeret årsagen og løst det. Vi ser systemet komme tilbage til stabilitet.
Systemet er nu blevet fuldt funktionsdygtigt.
* * Rodårsag * * Hændelsen skyldtes en udsendelse af en tjeneste, der drev en database migration. Holdet har identificeret, at denne migration indeholdt defekt kode og som følge heraf føre til database overbelastning, når man forsøger at implementere tjenesten. Som følge heraf var tjenesten delvist nede, indtil indsættelsen blev vendt tilbage. I løbet af denne tid, alle scanninger blev behandlet med lavere end forventet ydeevne.
Automatisk oversat fra den officielle hændelsesopdatering.
GitHub komponent: API anmodninger EU-erhvervsgrenens økonomiske situation
GitHub komponent: API anmodninger EU-erhvervsgrenens økonomiske situation
Automatisk oversat fra den officielle hændelsesopdatering.
GitHub komponent: Træk anmodninger EU-farvande i IIa og IV
GitHub komponent: Træk anmodninger EU-farvande i IIa og IV
GitHub komponent: Træk anmodninger EU-farvande i IIa og IV
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har bemærket forringet ydeevne i IAC Pull Request scanninger. Vi fejlfinding problemet.
Vi har identificeret årsagen til forsinkelserne og har iværksat modforanstaltninger.
Den forsinkelse, der førte til langsommelighed er næsten slut. Vi overvåger situationen.
Spørgsmålet er løst, og vi følger fortsat situationen.
Automatisk oversat fra den officielle hændelsesopdatering.
GitHub komponent: API anmodninger, Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Automatisk oversat fra den officielle hændelsesopdatering.
GitHub komponent: Webkrogs Tidligere hændelse i GitHub: https: / / stspg.io / syhr80rth84z
GitHub komponent: Webkrogs, Træk anmodninger Tidligere hændelse i GitHub: https: / / stspg.io / syhr80rth84z
GitHub komponent: Webkrogs, Træk anmodninger Tidligere hændelse i GitHub: https: / / stspg.io / syhr80rth84z
Automatisk oversat fra den officielle hændelsesopdatering.
På * * 1: 41 * * PM EDT, vi identificerede et problem forårsager forhøjede fejlrater under anmodning behandling i platformen UI. Problemet blev løst hurtigt, og platformen fungerer i øjeblikket normalt. Vores team fortsætter med aktivt at overvåge platformen for at sikre service stabilitet.
Hændelsen er blevet løst, og platformen fungerer normalt.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har bemærket en del af CLI Secrets scanninger mislykkedes. Vi undersøger aktivt problemet.
Vi har identificeret, at CLI version 3.17.1 introducerede den defekte adfærd. Nedrivning af CLI-version til 3.17.0 bør midlertidigt løse problemet, mens vi fortsætter med at forstå og løse den grundlæggende årsag.
En rettelse er blevet anvendt og funktionalitet er fuldt genoprettet; vi fortsætter med at overvåge for at sikre, at alt forbliver stabilt.
Automatisk oversat fra den officielle hændelsesopdatering.
På grund af øgede scanningsbelastninger, vi observeret forsinkelser i overtrædelse status opdateringer, som omfatter automatisk løsning af overtrædelser. Kilden til den pludselige stigning er blevet mindsket, og forsinkelsen er allerede faldende. Vi holder øje med situationen, indtil vi er normale igen
Vi fortsætter med at overvåge detektering behandling og de tilhørende forsinkelser i overtrædelse status opdateringer (herunder autoopløsning)
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har bemærket forringet ydeevne i flere systemkomponenter. Vi identificerer alle berørte komponenter og den egentlige årsag.
Vi har bemærket forringet ydeevne i flere komponenter af ansøgningen UI. Scans, samt Pull Request og CLI scanninger kan også blive påvirket.
Vi observerer forhøjede Redis timeout rater. Vi skalerer Redis klynge kapacitet til at afbøde virkningen og genoprette stabil service ydeevne
Regionen er kommet sig og fungerer normalt. Vi overvåger nøje systemets ydeevne for at sikre fortsat stabilitet
Systemet er nu fuldt funktionsdygtigt. Der bør ikke være mere forringet ydeevne. * * Oversigt * * Vi har observeret en periode med langsommelighed og periodiske timeouts, der påvirker forskellige systemfunktioner i EU-regionen, herunder applikationsgrænsefladen og pull request scanninger (PR). Spørgsmålet var primært forårsaget af et behandlingssystem, der nåede sine net- og hukommelseskapacitet grænser, forværret af en høj mængde automatiseret aktivitet fra en enkelt kilde. Vi har siden opgraderet den underliggende infrastruktur og gennemført sikkerhedsforanstaltninger for at forhindre lignende højvolumenaktiviteter i at påvirke systemet. Spørgsmålet er nu helt løst, og alle tjenester er vendt tilbage til forventede præstationsniveauer. * * Nøgletidslinje (IDT) * * • * * 13. juli 2026, 11: 44 IDT * *: Hændelse opdaget efter rapporter om UI langsommelighed og PR scanning forsinkelser. • * * 13. juli 2026, 12: 19 IDT * *: Infrastrukturflaskehals identificeret; beslutning om at opgradere behandlingsklyngen. • * * 13. juli 2026, 12: 26 IDT * *: En automatiseret højvolumenproces blev identificeret og deaktiveret for at reducere den umiddelbare belastning. • * * 13. juli 2026, 13: 09 IDT * *: Infrastrukturopgradering afsluttet; netgennemstrømningen vendte tilbage til normale niveauer. • * * 13. juli 2026, 15: 35 IDT * *: Alle backlogs ryddet, og hændelsen blev officielt løst. * * Rodårsag * * Hændelsen blev udløst af en kombination af faktorer: en processor klynge nåede sin maksimale netværk båndbredde og hukommelse kapacitet på grund af en underdimensioneret konfiguration for den aktuelle arbejdsbyrde. Dette blev yderligere belastet af en specifik automatiseret arbejdsgang, der genererede en usædvanlig stor mængde af opdateringsanmodninger. Desuden forhindrede en konfigurationsforskel i brevbehandlingsrørledningen i EU-regionen systemet i effektivt at håndtere den deraf følgende forsinkelse. * * Handlinger taget * * • * * Opgraderet infrastruktur * *: Bearbejdningsklyngen blev opgraderet til en højere kapacitet instans type at give mere netværk båndbredde og hukommelse. • * * Handicap High- Volume Source * *: En specifik klient id ansvarlig for overdreven trafik blev midlertidigt deaktiveret for at genoprette systemets stabilitet. • * * Genoprettede forbindelser * *: Berørte servicekomponenter blev genstartet for at sikre, at de genetablerede rene forbindelser til den opgraderede infrastruktur. • * * Øget parallelisme: Antallet af partitioner i den berørte meddelelse kø blev øget, så systemet til at behandle backlog hurtigere. * * Aktionsposter * * • * * Forbedre overvågningen * *: Implementere nye advarsler for netværk og hukommelse udnyttelse til at opdage kapacitetsproblemer, før de påvirker kunderne. • * * Optimer arbejdsgang * *: Refaktur status opdatering proces til batch anmodninger, væsentligt reducere belastningen på behandlingssystemet. • * * Implementér hastighedsbegrænsning * *: Indføre sikkerhedsforanstaltninger for at forhindre, at en enkelt kilde bruger uforholdsmæssigt store systemressourcer. • * * Standard regionale indstillinger * *: Der foretages en revision for at sikre, at indstillingerne for infrastruktur og meddelelseskø er konsekvente i alle regioner.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi har identificeret et problem, der kan forårsage * * unøjagtige overtrædelse tæller * * i * * nogle * * produkt dashboards og brugerdefinerede dashboard paneler, der er afhængige af overtrædelse data (ikke alle dashboards er berørt). Vi er allerede begyndt korrigerende arbejde, men det vil tage tid at fuldføre, og du kan se tal ændre som data er korrigeret. Vi vil dele en anden opdatering, når fixet er færdig kører og data nøjagtighed er fuldt restaureret.
Vi har gjort betydelige fremskridt med at korrigere de unøjagtige overtrædelsestællinger, der påvirker nogle produkter og brugerdefinerede dashboards. Status: * * Løsningen er gennemført med succes for langt de fleste konti, og fuld datanøjagtighed er blevet genoprettet. • * * Næste skridt: * * Vi er aktivt ved at løse problemet med det lille antal tilbageværende berørte konti.
Funktionaliteten genoprettes fuldt ud. Vi overvåger fortsat for at sikre, at alt forbliver stabilt.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi er i øjeblikket ved at undersøge et problem, der påvirker Maestro Risk Explorability, Risk AI genopfriskning, Maestro genopfriskning, og Graph AI tjenester.
Vi identificerede en firewall konfiguration problem, der var påvirker Maestro AI tjenester. Konfigurationen er blevet opdateret, og de berørte tjenester er kommet sig. Vi følger fortsat situationen og arbejder på yderligere stabilisering. Nogle forringet ydeevne kan stadig observeres, mens vi fuldføre yderligere forbedringer.
Spørgsmålet om Maestro AI tjenester er blevet løst. Maestro Risk Explorability, Risk AI genopfriskning, Maestro genopfriskning, og Graph AI er nu tilgængelige og fungerer normalt. * * Oversigt * * Den 9. juli 2026 oplevede kunder, der brugte Maestro-tjenesten i det europæiske produktionsmiljø, en periode med servicebesvær. Problemet begyndte efter en konfigurationsopdatering, der utilsigtet ændrede tjenestens regionale routing. Dette fik systemet til at forsøge forbindelser gennem et netværk sti, der manglede de nødvendige tilladelser og til en region, hvor specifikke behandlingsmodeller var utilgængelige. Problemet er blevet løst fuldt ud, og service er blevet genoprettet til alle berørte kunder. * * Nøgletidslinje (IDT) * * • * * 9. juli 2026, 12: 02 IDT: * * Hændelsen blev identificeret, og en undersøgelse blev indledt. • * * 9. juli 2026, 12: 07 IDT: * * Der blev udstedt offentlig meddelelse om afbrydelsen af tjenesten. • * * 9. juli 2026, 13: 00 IDT: * * Et netværkskonfiguration fix blev anvendt, genoprette primær forbindelse. • * * 9. juli 2026, 13: 39 IDT: * * Tjenesten blev fuldt restaureret efter gennemførelsen model fallbacks, og hændelsen blev markeret som løst. * * Rodårsag * * Service afbrydelsen blev udløst af en nylig opdatering til autentificering og konfiguration proces. Denne opdatering indførte en konflikt i, hvordan systemet identificerede sin operationelle region. Specifikt, en automatiseret opdateringsproces tilsidesatte manuelle indstillinger, routing trafik til et andet regionalt endpoint. Denne nye vej blev blokeret af en manglende netværkssikkerhedsregel og forsøgte at bruge en behandlingsmodel, der ikke blev understøttet i den pågældende region, hvilket førte til servicesvigt. * * Handlinger taget * * • * * Gendannelse af netværksforbindelse: * * Manuel opdatering af netsikkerhedsregler for at muliggøre sikker trafik gennem det nye regionale endpoint. • * * Implementeret model Fallbacks: * * Konfigure systemet til at bruge alternative behandlingsmodeller for at sikre umiddelbar service tilgængelighed, mens langsigtede regionale konfigurationer blev justeret. • * * Opdateret statusmeddelelser: * * Bevarede realtidsopdateringer for interessenter og kunder under hele inddrivelsesprocessen. * * Aktionsposter * * • * * Standardindstilling Præcision: * * Opdatér implementeringsarbejdsgangen for at forhindre automatiserede processer fra lydløst overordnede kritiske miljøindstillinger. • * * Infrastrukturrevision: * * Gennemføre en omfattende gennemgang af netsikkerhedsreglerne på tværs af alle regioner for at sikre konsekvens og forhindre lignende forbindelseshuller. • * * Forbedre automatisk overvågning: * * Implementere end-to-end sundhedstjek og syntetiske sonder til at opdage regionale konnektivitet spørgsmål automatisk, før de påvirker brugerne. • * * forbedre implementeringspolitikker: * * Etablere nye retningslinjer for at sikre, at konfigurationsændringer anvendes og valideres i produktionslignende miljøer oftere for at reducere risikoen for "gamle" opdateringer.
Automatisk oversat fra den officielle hændelsesopdatering.
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.
* * Undersøgelse - problemer med overtrædelser og Custom Dashboards (Prod-US) * * Vi er i øjeblikket ved at undersøge et problem i vores * * Prod- US * * miljø, hvor overtrædelser undlader at indlæse. Som et resultat, kan brugerdefinerede dashboard paneler, der er afhængige af overtrædelse data også undlade at rendere eller vise fejl. Vores ingeniørhold undersøger aktivt årsagen, og vi vil levere opdateringer her, som vi lærer mere. Vi undskylder ulejligheden.
Der er blevet udsendt et fix for de spørgsmål, der påvirker overtrædelser og brugerdefinerede dashboards i Prod-US. Vi overvåger aktivt miljøet for at sikre, at tjenesterne genoprettes fuldt ud.
Kernen er blevet løst, og overtrædelser og brugerdefinerede dashboards bør nu fungere som normalt. Vores team overvåger aktivt datasynkroniseringen for at løse eventuelle resterende uoverensstemmelser med nyere overtrædelser. Vi vil levere en endelig opdatering, når synkroniseringen er færdig.
Vi fortsætter med at overvåge datasynkroniseringsprocessen for nye overtrædelser i UI. Mens funktionalitet er blevet genoprettet, kan det tage op til * * 6 timer * * for alle de seneste data til fuldt ud at indhente og reflektere præcist. Vi vil give en endelig opdatering, når synkroniseringen er færdig.
Datasynkroniseringen er færdig, og alle nylige overtrædelser har haft succes i UI. Overtrædelser og brugerdefinerede dashboards fungerer normalt, og hændelsen er helt løst. Vi sætter pris på din tålmodighed, da vi arbejdede for at genoprette fuld service.
Funktionaliteten genoprettes fuldt ud. Vi overvåger fortsat for at sikre, at alt forbliver stabilt.
Automatisk oversat fra den officielle hændelsesopdatering.
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