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
Automatisch aus der offiziellen Störungsmeldung übersetzt.
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.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen ein Problem, das dazu führt, dass ältere Ereignisse wiederaufbereitet werden. **Auswirkungen:** Einige Workflows laufen möglicherweise erneut, was zu doppelten Warnungen führen kann. PR-Scans können sich auch verzögern.
Wir haben den Verarbeitungsrückstand behoben, der durch ein Problem während einer Kafka-Migration verursacht wurde. Das Problem führte dazu, dass ältere Ereignisse neben neuen Ereignissen verarbeitet wurden, was zu Verzögerungen führte und möglicherweise einige Verstöße mit einem veralteten Status aktualisiert hat. Die normale Verarbeitung wurde wiederhergestellt. Kunden können jedoch immer noch einige Verstöße mit einem veralteten Status sehen, während wir die betroffenen Aufzeichnungen identifizieren und korrigieren. PR-Scans wurden nicht verzögert oder neu bearbeitet und Workflows wurden nicht beeinflusst. Wir setzen die Sanierung fort und beobachten das System genau.
Die normale Verarbeitung wurde wiederhergestellt und der Vorfall wird nun überwacht. Eine kleine Anzahl von Kunden kann immer noch eine begrenzte Anzahl von Verstößen mit einem veralteten Status als Folge des Vorfalls sehen. Wir haben die potenziell betroffenen Umgebungen identifiziert und arbeiten daran, die betroffenen Aufzeichnungen zu korrigieren.
Das System ist voll funktionsfähig. Eine kleine Anzahl von Kunden kann immer noch eine begrenzte Anzahl von Verstößen mit einem veralteten Status als Folge des Vorfalls sehen. Wir haben die potenziell betroffenen Umgebungen identifiziert und arbeiten daran, die betroffenen Aufzeichnungen zu korrigieren.
The platform is now fully operational and processing normally
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Das Team identifizierte ein Problem mit verschlechterter Leistung beim Scannen. Es kann zu Verzögerungen beim Starten, Ausführen und Abschluss von Scans kommen. Alle Scan-Typen können betroffen sein (Pull Request und CLI-Scans auch). Das Team hat ein Problem mit einer Fehlfunktion im Einsatz identifiziert, und das Problem sollte in Kürze behoben werden.
Das Team hat die Ursache identifiziert und behoben. Wir sehen, wie das System wieder zur Stabilität zurückkehrt.
Das System ist nun wieder voll funktionsfähig.
**Wurzelursache** Der Vorfall wurde durch die Bereitstellung eines Dienstes verursacht, der eine Datenbankmigration durchführte. Das Team hat festgestellt, dass diese Migration fehlerhaften Code enthielt und infolgedessen zu einer Überlastung der Datenbank führte, wenn versucht wurde, den Dienst bereitzustellen. Infolgedessen war der Dienst teilweise ausgefallen, bis die Bereitstellung rückgängig gemacht wurde. Während dieser Zeit wurden alle Scans mit einer geringeren als erwarteten Leistung verarbeitet.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
GitHub-Komponente: API Requests GitHub-Vorfall: https://stspg.io/vr201n49yl53
GitHub-Komponente: API Requests GitHub-Vorfall: https://stspg.io/vr201n49yl53
Automatisch aus der offiziellen Störungsmeldung übersetzt.
GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/sm1tp7kfm4vj
GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/sm1tp7kfm4vj
GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/sm1tp7kfm4vj
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben eine verschlechterte Leistung bei IaC Pull Request-Scans festgestellt. Wir sind dabei, das Problem zu beheben.
Wir haben die Ursache der Langsamkeit identifiziert und setzen Gegenmaßnahmen um.
Die Verzögerung, die zu Langsamkeiten führte, ist fast vorbei. Wir beobachten die Situation.
Das Problem ist gelöst, und wir beobachten die Situation weiterhin.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
GitHub-Komponente: API Requests, Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Automatisch aus der offiziellen Störungsmeldung übersetzt.
GitHub-Komponente: Webhooks Ursprünglicher GitHub-Vorfall: https://stspg.io/syhr80rth84z
GitHub-Komponente: Webhooks, Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/syhr80rth84z
GitHub-Komponente: Webhooks, Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/syhr80rth84z
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Bei **1:41 ** PM EDT haben wir ein Problem festgestellt, das erhöhte Fehlerraten während der Anfrageverarbeitung in der Plattform-Benutzeroberfläche verursacht hat. Das Problem wurde umgehend gemildert und die Plattform arbeitet derzeit normal. Unser Team überwacht die Plattform weiterhin aktiv, um die Servicestabilität zu gewährleisten.
Der Vorfall wurde behoben und die Plattform funktioniert normal.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben festgestellt, dass ein Teil der CLI Secrets-Scans fehlgeschlagen ist. Wir triagieren das Problem aktiv.
Wir haben festgestellt, dass CLI Version 3.17.1 das fehlerhafte Verhalten eingeführt hat. Der Abbau der CLI-Version auf 3.17.0 sollte das Problem vorübergehend beheben, während wir die Ursache weiterhin verstehen und beheben.
Ein Fix wurde angewendet und die Funktionalität wurde vollständig wiederhergestellt; wir überwachen weiterhin, um sicherzustellen, dass alles stabil bleibt.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Aufgrund der erhöhten Scan-Auslastung beobachteten wir Verzögerungen bei der Aktualisierung des Verletzungsstatus, einschließlich der automatischen Auflösung von Verstößen. Die Quelle des plötzlichen Anstiegs wurde gemildert und die Verzögerung nimmt bereits ab. Wir werden die Situation weiter beobachten, bis wir wieder normal sind
Wir überwachen weiterhin die Erkennungsverarbeitung und die damit verbundenen Verzögerungen bei der Aktualisierung des Verletzungsstatus (einschließlich der automatischen Auflösung)
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben eine verschlechterte Leistung in mehreren Systemkomponenten festgestellt. Wir identifizieren alle betroffenen Komponenten und identifizieren die Ursache.
Wir haben eine verschlechterte Leistung in mehreren Komponenten der Anwendungsoberfläche festgestellt. Scans sowie Pull Request und CLI Scans können ebenfalls betroffen sein.
Wir beobachten erhöhte Redis-Timeout-Raten. Wir skalieren die Redis-Clusterkapazität, um die Auswirkungen zu minimieren und eine stabile Serviceleistung wiederherzustellen
Die Region hat sich erholt und funktioniert normal. Wir überwachen die Systemleistung genau, um eine anhaltende Stabilität zu gewährleisten
Das System ist nun voll funktionsfähig. Es sollte keine verschlechterte Leistung mehr geben. **Zusammenfassung** Wir beobachteten eine Zeit der Langsamkeit und intermittierenden Timeouts, die verschiedene Systemfunktionen in der EU-Region beeinflussten, einschließlich der Anwendungsschnittstelle und Pull Request (PR) Scans. Das Problem wurde in erster Linie dadurch verursacht, dass ein Verarbeitungssystem seine Netzwerk- und Speicherkapazitätsgrenzen erreichte, was durch ein hohes Volumen an automatisierten Aktivitäten aus einer einzigen Quelle noch verschärft wurde. Seitdem haben wir die zugrunde liegende Infrastruktur aufgerüstet und Sicherheitsvorkehrungen getroffen, um zu verhindern, dass sich ähnliche großvolumige Aktivitäten auf das System auswirken. Das Problem ist nun vollständig gelöst, und alle Dienste sind auf das erwartete Leistungsniveau zurückgekehrt. **Key Timeline (IDT)** • ** 13. Juli 2026, 11:44 IDT**: Ein Vorfall wurde nach Berichten über UI-Langsamkeit und PR-Scan-Verzögerungen erkannt. ** 13. Juli 2026, 12:19 IDT**: Infrastrukturengpässe identifiziert; Entscheidung zur Aktualisierung des Verarbeitungsclusters getroffen. ** 13. Juli 2026, 12:26 IDT**: Ein hochvolumiger automatisierter Prozess wurde identifiziert und deaktiviert, um die sofortige Belastung zu reduzieren. ** 13. Juli 2026, 13:09 IDT**: Infrastruktur-Upgrade abgeschlossen; Netzwerkdurchsatz wieder auf normales Niveau. ** 13. Juli 2026, 15:35 IDT**: Alle Rückstände wurden gelöscht und der Vorfall wurde offiziell behoben. **Wurzelursache** Der Vorfall wurde durch eine Kombination von Faktoren ausgelöst: Ein Verarbeitungscluster erreichte seine maximale Netzwerkbandbreite und Speicherkapazität aufgrund einer unterdimensionierten Konfiguration für die aktuelle Arbeitslast. Dies wurde durch einen speziellen automatisierten Workflow, der ein ungewöhnlich hohes Volumen an Update-Anfragen generierte, weiter belastet. Darüber hinaus verhinderte ein Konfigurationsunterschied in der Nachrichtenverarbeitungspipeline in der EU-Region, dass das System den resultierenden Rückstand effektiv verarbeiten konnte. **Ergriffene Maßnahmen** • **Aktualisierte Infrastruktur**: Der Verarbeitungscluster wurde auf einen Instanztyp mit höherer Kapazität aufgerüstet, um mehr Netzwerkbandbreite und Speicher bereitzustellen. • **Disabled High-Volume Source**: Eine spezifische Client-ID, die für übermäßigen Datenverkehr verantwortlich ist, wurde vorübergehend deaktiviert, um die Systemstabilität wiederherzustellen. **Wiederhergestellte Konnektivität**: Betroffene Servicekomponenten wurden neu gestartet, um sicherzustellen, dass sie saubere Verbindungen zur aktualisierten Infrastruktur wiederherstellen. • **Erhöhte Verarbeitungsparallelität**: Die Anzahl der Partitionen in der betroffenen Nachrichtenwarteschlange wurde erhöht, damit das System den Backlog schneller verarbeiten kann. **Aktionspunkte ** **Enhance Monitoring**: Implementieren Sie neue Benachrichtigungen zur Netzwerk- und Speicherauslastung, um Kapazitätsprobleme zu erkennen, bevor sie sich auf Kunden auswirken. • **Update Workflow optimieren**: Refaktorisierung des Statusaktualisierungsprozesses für Batch-Anforderungen, wodurch die Belastung des Verarbeitungssystems erheblich reduziert wird. • **Implementieren Sie Rate Limiting **: Einführung von Sicherheitsvorkehrungen, um zu verhindern, dass einzelne Quellen unverhältnismäßige Systemressourcen verbrauchen. • **Regionale Konfigurationen standardisieren**: Führen Sie ein Audit durch, um sicherzustellen, dass die Einstellungen für die Infrastruktur- und Nachrichtenwarteschlange in allen Regionen konsistent sind.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben ein Problem identifiziert, das in einigen Produkt-Dashboards und benutzerdefinierten Dashboard-Panels, die auf Verletzungsdaten beruhen, **ungenaue Verstöße verursachen kann ** (nicht alle Dashboards sind betroffen). Wir haben bereits mit der Korrekturarbeit begonnen, aber es wird einige Zeit dauern, bis sie vollständig abgeschlossen ist, und Sie können sehen, dass sich die Zählungen ändern, wenn die Daten korrigiert werden. Wir werden ein weiteres Update teilen, sobald der Fix ausgeführt wurde und die Datengenauigkeit vollständig wiederhergestellt ist.
Wir haben erhebliche Fortschritte bei der Korrektur der ungenauen Anzahl von Verstößen gemacht, die einige Produkt- und kundenspezifische Dashboards betreffen. ** Aktueller Status:** Der Fix wurde für die überwiegende Mehrheit der Konten erfolgreich abgeschlossen und die vollständige Datengenauigkeit wurde wiederhergestellt. ** Nächste Schritte:** Wir lösen das Problem für die kleine Anzahl der verbleibenden betroffenen Konten aktiv.
Die Funktionalität ist vollständig wiederhergestellt; wir überwachen weiterhin, um sicherzustellen, dass alles stabil bleibt.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit ein Problem mit Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation und Graph AI Services.
Wir haben ein Firewall-Konfigurationsproblem identifiziert, das sich auf die Maestro AI-Dienste auswirkte. Die Konfiguration wurde aktualisiert und die betroffenen Dienste wurden wiederhergestellt. Wir beobachten die Situation weiter und arbeiten an einer weiteren Stabilisierung. Einige verschlechterte Leistungen können noch beobachtet werden, während wir zusätzliche Verbesserungen durchführen.
Das Problem der Maestro AI-Dienste wurde behoben. Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation und Graph AI sind jetzt verfügbar und funktionieren normal. **Zusammenfassung** Am 9. Juli 2026 erlebten Kunden, die den Maestro-Service in der europäischen Produktionsumgebung nutzten, eine Zeit der Service-Nichtverfügbarkeit. Das Problem begann nach einem Konfigurationsupdate, das versehentlich das regionale Routing des Dienstes veränderte. Dies führte dazu, dass das System Verbindungen über einen Netzwerkpfad ohne die erforderlichen Berechtigungen und zu einer Region versuchte, in der bestimmte Verarbeitungsmodelle nicht verfügbar waren. Das Problem wurde vollständig gelöst und der Service für alle betroffenen Kunden wiederhergestellt. **Key Timeline (IDT)** • **Juli 9, 2026, 12:02 IDT:** Der Vorfall wurde identifiziert und eine Untersuchung eingeleitet. • ** 9. Juli 2026, 12:07 IDT:** Es wurde eine öffentliche Benachrichtigung über die Serviceunterbrechung herausgegeben. • **Juli 9, 2026, 13:00 IDT:** Ein Netzwerkkonfigurations-Fix wurde angewendet, um die primäre Konnektivität wiederherzustellen. • **Juli 9, 2026, 13:39 IDT:** Der Service wurde nach der Implementierung von Modell-Fallbacks vollständig wiederhergestellt und der Vorfall wurde als behoben markiert. **Wurzelursache** Die Dienstunterbrechung wurde durch ein kürzliches Update des Authentifizierungs- und Konfigurationsprozesses ausgelöst. Dieses Update führte zu einem Konflikt darin, wie das System seine Betriebsregion identifizierte. Insbesondere ein automatisierter Update-Prozess überschrieb manuelle Einstellungen und leitete den Datenverkehr zu einem anderen regionalen Endpunkt. Dieser neue Pfad wurde durch eine fehlende Netzwerksicherheitsregel blockiert und versuchte, ein Verarbeitungsmodell zu verwenden, das in dieser spezifischen Region nicht unterstützt wurde, was zu einem Dienstausfall führte. **Ergriffene Maßnahmen** • **Wiederhergestellte Netzwerkverbindung:** Manuell aktualisierte Netzwerksicherheitsregeln, um sicheren Datenverkehr über den neuen regionalen Endpunkt zu ermöglichen. **Implementierte Modell-Fallbacks:** Das System wurde so konfiguriert, dass es alternative Verarbeitungsmodelle verwendet, um eine sofortige Serviceverfügbarkeit zu gewährleisten, während langfristige regionale Konfigurationen angepasst wurden. • **Aktualisierte Statuskommunikation:** Pflegete Echtzeit-Updates für Stakeholder und Kunden während des gesamten Wiederherstellungsprozesses. **Aktionspunkte ** • **Konfigurationspräzedenz standardisieren:** Aktualisieren Sie den Bereitstellungsworkflow, um zu verhindern, dass automatisierte Prozesse die kritischen Umgebungseinstellungen stillschweigend überschreiben. **Infrastructure Audit:** Führen Sie eine umfassende Überprüfung der Netzwerksicherheitsregeln in allen Regionen durch, um Konsistenz zu gewährleisten und ähnliche Verbindungslücken zu vermeiden. **Verbesserte automatisierte Überwachung:** Implementieren Sie End-to-End-Gesundheitschecks und synthetische Sonden, um regionale Konnektivitätsprobleme automatisch zu erkennen, bevor sie sich auf die Benutzer auswirken. • **Verbesserte Bereitstellungsrichtlinien:** Erstellen Sie neue Richtlinien, um sicherzustellen, dass Konfigurationsänderungen häufiger in produktionsähnlichen Umgebungen bereitgestellt und validiert werden, um das Risiko von "stalen" Updates zu verringern.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
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.
**Untersuchung - Probleme mit Verstößen und benutzerdefinierten Dashboards (Prod-US) ** Wir untersuchen derzeit ein Problem in unserer **Prod-US**-Umgebung, in der Verstöße nicht geladen werden. Infolgedessen können benutzerdefinierte Dashboard-Panels, die auf Verletzungsdaten angewiesen sind, auch Fehler darstellen oder anzeigen. Unser Engineering-Team befasst sich aktiv mit der Ursache, und wir werden hier Updates bereitstellen, wenn wir mehr erfahren. Wir entschuldigen uns für die Unannehmlichkeiten.
Es wurde ein Fix für die Probleme mit Verstößen und benutzerdefinierten Dashboards in Prod-US bereitgestellt. Wir überwachen aktiv die Umwelt, um sicherzustellen, dass die Dienste vollständig wiederhergestellt werden.
Das Kernproblem wurde behoben, und Verstöße und benutzerdefinierte Dashboards sollten jetzt wie gewohnt funktionieren. Unser Team überwacht die Datensynchronisierung aktiv, um verbleibende Diskrepanzen mit neueren Verstößen zu beheben. Wir werden ein endgültiges update bereitstellen, sobald die synchronisierung abgeschlossen ist.
Wir überwachen weiterhin den Datensynchronisationsprozess auf neue Verstöße in der Benutzeroberfläche. Während die Funktionalität wiederhergestellt wurde, kann es bis zu **6 Stunden** dauern, bis alle aktuellen Daten vollständig aufgeholt und genau reflektiert wurden. Wir werden ein endgültiges Update bereitstellen, sobald die Synchronisierung abgeschlossen ist.
Die Datensynchronisation ist abgeschlossen und alle jüngsten Verstöße haben sich erfolgreich in der Benutzeroberfläche befunden. Verstöße und benutzerdefinierte Dashboards funktionieren normal und der Vorfall ist vollständig behoben. Wir schätzen Ihre Geduld, als wir daran gearbeitet haben, den vollen Service wiederherzustellen.
Die Funktionalität ist vollständig wiederhergestellt; wir überwachen weiterhin, um sicherzustellen, dass alles stabil bleibt.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
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