Status: Resolved AWS has confirmed that the issue has been fully mitigated and we are currently not observing any related issues. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
 </ul>

Infrastructure Provisioning Delays

Status: Resolved The data synchronization is complete, and all recent violations have successfully populated in the UI.
Violations and custom dashboards are functioning normally, and the incident is fully resolved. We appreciate your patience as we worked to restore full service. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
 </ul>

Issues with Violations and Custom Dashboards (Prod-US)

Status: Resolved 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. Affected components
 <ul>
 <li>API (US Environment) (Operational)</li>
 </ul>

SAST, SCA and Secret scans slowness

Status: Resolved Summary
During the incident, customers experienced delays and temporary disruptions in on demand scans. The issue was caused by a number of redundant SCA scans as well as unoptimized reachability scans. As a result, processing capacity was improperly used for redundant, duplicate, scans. A corrective update for both issues was deployed to stabilize the environment, and the processing environment has since returned to expected performance levels.

Key Timeline (IDT)

• 01.06.2026: Unoptimized code responsible for reachability scans was introduced.
• 03.06.2026: A faulty code responsible for redundant SCA scans was introduced.
• 11.06.2026, 16:00 IDT: Increased processing delays were detected, and an investigation into the scanning service began.
• 11.06.2026, 17:00 IDT: The root cause for redundant SCA scans was identified, and the team began working on improving the behavior.
• 12.06.2026, 10:30 IDT: The root cause of redundant SCA scans was resolved.
• 12.06.2026, 17:00 IDT: The root cause for degraded performance in reachability scans was identified.
• 15.06.2026, 16:00 IDT: A corrective update was deployed to restore the optimization of reachability scans.
• 15.06.2026, 17:00 IDT: System stability was confirmed.


Root Cause
The issue was triggered by a combination of two issues:

1. Redundant SCA scans -- Upon receiving a new branch created event from the source code manager, the system attempted to scan all available branches that were configured to be scanned in the repository. In extreme cases, the team has found a magnitude of new scans started instead of one scan, when a branch was created. A faulty code introduced this bug on 03.06.2026 and got resolved on 12.06.2026
2. Unoptimized reachability scans -- Reachability scanner in the processing environment, has been configured to scan a set of programming languages. However, due to misconfiguration, the scanner was also attempting to scan programming languages that have not been configured to be scanned. Additionally, the scanner has been running on programming languages that are not stable yet, and in extreme cases, it caused a portion of scans to be stuck until they got timed out.


Actions Taken

• Deployed a corrective update to remove redundant SCA scans.
• Deployed a performance upgrade to reachability scans.


Action Items

• Improve monitoring to better understand the behavior of the processing environment.
• Improve scanning optimization for all scan types. Affected components
 <ul>
 <li>API (US Environment) (Operational)</li>
 </ul>

Degraded performance in on demand scans

Status: Resolved Summary
During the incident, customers experienced delays and temporary disruptions in scans. The issue was caused by a degraded performance of a process responsible for starting the scans. This means that the processing environment was underutilized even though there were enqueued scans. A corrective update was deployed to stabilize the environment, and the system has since returned to expected performance levels.

Key Timeline (IDT)

• 07.06.2026, 07:00 IDT: Degraded performance of scans began.
• 08.06.2026, 11:00 IDT: Degraded performance was noted and the investigation began.
• 08.06.2026, 13:15 IDT: A bottleneck was identified and a corrective update was deployed. 
• 08.06.2026, 14:00 IDT: It was confirmed that the update increased the throughput of the system.
• 09.06.2026, 14:00 IDT: System stability was confirmed, and the system was restored to normal operation.


Root Cause
The issue was triggered by degraded performance of a process responsible for starting scans. This caused the processing environment to be underutilized (even as low as 30% processing capacity), despite there being enqueued scans.

The root cause of the degraded performance has been identified in a race condition when attempting to rerun a failed scan. When attempting to rescan, the system occasionally encountered an error, because the first attempt of a scan failed, and the job was in terminating state. This resulted in extensive retries of the starting the rescans, which caused the degraded performance.

Actions Taken

• Deployed a corrective update to the bottleneck process.
• Restored expected processing performance.
• Improved monitoring to detect degraded performance.


Action Items

• Further improve monitoring to detect degraded performance.
• Further improve the performance of the bottleneck process. Affected components
 <ul>
 <li>API (US Environment) (Operational)</li>
 </ul>

Status: Resolved The issue was resolved. The system is fully stable now Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
 </ul>

Slow SAST PR scans

Status: Resolved Summary

Between April 14 and April 28, 2026, a processing issue occurred within our scanning workflow that prevented a subset of code update events from being fully processed. As a result, some security findings may not have been updated or resolved as expected in the platform. The issue was caused by an update to the processing system that introduced a conflict in how data was written to the database. The issue has been fully resolved, and all affected data has been reprocessed to ensure accuracy.

Key Timeline (IDT)

• April 14, 2026, 09:00 IDT: A new update was deployed to the processing system which introduced the underlying issue.
• April 28, 2026, 15:30 IDT: A subsequent system update was rolled out that inadvertently corrected the processing error.
• May 4, 2026, 11:00 IDT: Internal teams identified reports of inconsistent status updates and began a technical investigation.
• May 6, 2026, 10:00 IDT: A formal incident was initiated to analyze the full scope of the impact and coordinate remediation.
• May 7, 2026, 14:00 IDT: Data collection was completed to identify all repositories and branches that required reprocessing.
• May 8, 2026, 08:00 IDT: Reprocessing of affected data began for several scanning modules.
• May 9, 2026, 18:00 IDT: Initial reprocessing for the majority of modules was successfully completed.
• June 11, 2026, 12:00 IDT: Final reprocessing for all remaining modules was completed, and the incident was officially closed.

Root Cause

The issue was triggered by a change in the update process that attempted to perform multiple database operations simultaneously within the same request. This led to connectivity conflicts and prevented certain background tasks from completing successfully. Consequently, a small portion of events were not recorded, leading to delays in updating the status of findings for customers.

Actions Taken

• Deployed a corrective update to the processing system to ensure stable database interactions.
• Conducted a comprehensive data analysis to identify all events that were missed during the affected period.
• Triggered system-wide rescans for all affected branches to restore the expected state of all findings.
• Verified that all processed updates are now reflecting correctly across the platform.

Action Items

• Enhance system logging to provide better visibility into background processing failures.
• Implement automated alerts for specific error patterns to decrease detection time.
• Improve the scalability of the underlying processing services to handle high volumes more efficiently.
• Develop improved internal tools for bulk data correction and status verification. Affected components
 <ul>
 <li>API (EU Environment) (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>EU Environment (Operational)</li>
<li>US Environment (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
 </ul>

Unprocessed Push Event

Status: Resolved Summary
On June 10, 2026, customers may have experienced intermittent issues with their GitHub integrations due to an external authentication incident on GitHub's side. This resulted in some integrations temporarily reporting invalid access tokens and a brief pause in repository syncing and scanning. The issue was resolved once the external provider restored their authentication services. All integrations have automatically returned to normal operation, and no customer action is required.

Key Timeline (IDT)

• June 10, 2026, 18:20 IDT: The external provider began experiencing authentication issues affecting API requests.
• June 10, 2026, 18:20 IDT: Our processing system began receiving intermittent unauthorized responses, leading to temporary integration errors and paused syncing.
• June 10, 2026, 19:39 IDT: The external provider identified and mitigated the faulty component, resolving the incident.
• June 10, 2026, 19:39 IDT: Integrations automatically re-validated, and expected processing behavior was restored.



Root Cause
The incident was caused by an external authentication failure at GitHub. During this window, the provider's API erroneously returned "Unauthorized" responses for a portion of traffic. Our system interpreted these responses as revoked access tokens, which triggered temporary integration error states and paused background workflows.

Actions Taken

• Monitored the external incident status and its impact on our integration workflows.
• Verified that integrations automatically recovered and resumed syncing once the external provider restored service.
• Confirmed that no manual re-authentication was necessary for affected customers.



Action Items

• Improve internal handling of intermittent authentication errors to better distinguish between temporary external outages and actual token revocations.
• Enhance monitoring to more quickly identify when third-party service disruptions impact integration health. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
 </ul>

GitHub Authentication Incident Affecting Cycode GitHub Integrations

Status: Resolved The system is now fully stable Affected components
 <ul>
 <li>API (US Environment) (Operational)</li>
 </ul>

Degraded performance in SAST PR scans

Status: Resolved The incident has been resolved. We will provide the RCA shortly. Affected components
 <ul>
 <li>Application/UI (EU Environment) (Operational)</li>
<li>US Environment (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
<li>EU Environment (Operational)</li>
 </ul>

Slow SAST scans

Status: Resolved Summary

Between 16:00 and 17:30 UTC on May 28, we observed an issue where integration connections were intermittently reported as invalid. During this period, the processing of pull requests was paused until connection tokens were successfully refreshed. As a result, some pull requests may have experienced delays or remained in a stuck state. The issue is now resolved, and processing has resumed normally.

Key Timeline (UTC)

• May 28, 16:00 UTC: A high rate of integration connections were reported as invalid, and pull request processing was paused.
• May 28, 17:00 UTC: The external service began returning successful responses, and the system started marking integrations as valid.
• May 28, 17:30 UTC: Connection tokens were successfully refreshed and pull request processing resumed.

Root Cause

The issue was caused by an external service provider returning "no access" responses during a routine validity check. This caused the system to mark integrations as invalid and pause processing. The failures occurred simultaneously across many unrelated accounts and were resolved without any changes on our side, indicating a service disruption on the provider's side.

While the observed behavior clearly points to the external provider, we are continuing to work with GitHub to better understand the underlying cause of this transient failure.

Actions Taken

• Restored expected processing behavior once connection tokens were successfully refreshed.
• Monitored the system to ensure all integrations returned to a valid state.

Action Items

• Improve monitoring to detect similar external service anomalies.
• Add alerting on simultaneous validity-check failures across unrelated accounts. Affected components
 <ul>
 <li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>EU Environment (Operational)</li>
<li>US Environment (Operational)</li>
 </ul>

GitHub PR Delays

Status: Resolved Summary
Between May 15 and May 28, 2026, a processing delay was identified affecting dependency update workflows for several large accounts. During this period, customers may have experienced significant lag in the time required to process and reflect dependency updates within the system. The issue was caused by an inefficiency in how the database retrieved specific project records, leading to temporary performance degradation. The issue has been fully resolved, and processing speeds have returned to expected levels.

Key Timeline (IDT)
May 17, 2026, 09:00 IDT: Initial reports of increased processing times for dependency updates were observed.
May 24, 2026, 14:30 IDT: System resources were increased to provide temporary relief while the investigation continued.
May 28, 2026, 11:15 IDT: Technical analysis identified a specific database query that was not utilizing the most efficient lookup path.
May 30, 2026, 16:45 IDT: A corrective update to the database indexing structure was deployed.
May 31, 2026, 10:00 IDT: Monitoring confirmed that processing latency returned to sub-millisecond levels and the backlog was cleared.

Root Cause
The root cause was a performance regression in the update workflow’s data retrieval process. The database’s automated query planner began selecting a less efficient path to locate project references. Because the system was searching through a very large volume of records, this inefficient path resulted in the system scanning thousands of unnecessary rows for each update. This led to high disk activity and significant delays, particularly for accounts with a high density of shared dependencies across many projects.

Actions Taken

1. Resource Scaling: Temporarily increased database memory and processing power to mitigate the immediate impact on customers.
2. Database Optimization: Performed a deep analysis of query execution plans to identify the specific bottleneck.
3. Index Refinement: Replaced an existing database index with an optimized version that ensures the query planner always selects the most direct path for data retrieval.
4. Validation: Verified the fix across all environments to ensure the new indexing structure supports both data integrity and high-speed lookups.

Action Items

1. Enhanced Monitoring: Implement more granular alerts for database query performance to detect similar planning inefficiencies before they impact customers.
2. Optimization Standards: Update internal database design guidelines to prevent overlapping index patterns that can confuse automated query planners.
3. Performance Testing: Incorporate “cold cache” scenarios into performance testing for large-scale data operations to better simulate real-world disk I/O constraints. Affected components
 <ul>
 <li>EU Environment (Operational)</li>
<li>US Environment (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
 </ul>

Slow SCA scans

Status: Resolved Summary

Between May 15 and May 28, 2026, a processing delay was identified affecting dependency update workflows for several large accounts. During this period, customers may have experienced significant lag in the time required to process and reflect dependency updates within the system. The issue was caused by an inefficiency in how the database retrieved specific project records, leading to temporary performance degradation. The issue has been fully resolved, and processing speeds have returned to expected levels.

Key Timeline (IDT)

May 17, 2026, 09:00 IDT: Initial reports of increased processing times for dependency updates were observed.

May 24, 2026, 14:30 IDT: System resources were increased to provide temporary relief while the investigation continued.

May 28, 2026, 11:15 IDT: Technical analysis identified a specific database query that was not utilizing the most efficient lookup path.

May 30, 2026, 16:45 IDT: A corrective update to the database indexing structure was deployed.

May 31, 2026, 10:00 IDT: Monitoring confirmed that processing latency returned to sub-millisecond levels and the backlog was cleared.

Root Cause

The root cause was a performance regression in the update workflow's data retrieval process. The database's automated query planner began selecting a less efficient path to locate project references. Because the system was searching through a very large volume of records, this inefficient path resulted in the system scanning thousands of unnecessary rows for each update. This led to high disk activity and significant delays, particularly for accounts with a high density of shared dependencies across many projects.

Actions Taken

1. Resource Scaling: Temporarily increased database memory and processing power to mitigate the immediate impact on customers.
2. Database Optimization: Performed a deep analysis of query execution plans to identify the specific bottleneck.
3. Index Refinement: Replaced an existing database index with an optimized version that ensures the query planner always selects the most direct path for data retrieval.
4. Validation: Verified the fix across all environments to ensure the new indexing structure supports both data integrity and high-speed lookups.

Action Items

1. Enhanced Monitoring: Implement more granular alerts for database query performance to detect similar planning inefficiencies before they impact customers.
2. Optimization Standards: Update internal database design guidelines to prevent overlapping index patterns that can confuse automated query planners.
3. Performance Testing: Incorporate "cold cache" scenarios into performance testing for large-scale data operations to better simulate real-world disk I/O constraints. Affected components
 <ul>
 <li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
<li>EU Environment (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>US Environment (Operational)</li>
 </ul>

Status: Resolved Resolved Affected components
 <ul>
 <li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
<li>US Environment (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>EU Environment (Operational)</li>
 </ul>

PR Scans Stuck in "Waiting" Status

Status: Resolved Summary
On May 8, 2026, a temporary issue within our internal processing system interrupted the routine renewal of GitLab access credentials for a subset of integrations. This caused affected integrations to stop syncing and appear as disconnected. Because the affected credentials were no longer valid, they could not be restored from our end — each affected integration had to be manually re-authenticated by the customer in order to resume syncing. No customer data was lost or exposed, and no credential security was compromised.

Key Timeline (UTC)
May 8, 2026, 21:10 UTC: A temporary slowdown in the database processing system began affecting credential updates.
May 8, 2026, 21:40 UTC: The system identified that a subset of GitLab integrations were unable to complete their routine credential renewals.
May 8, 2026, 22:30 UTC: The root cause was identified as a failure to save newly issued credentials during the renewal process.
May 8, 2026, 23:30 UTC: Corrective measures were implemented to stabilize the update workflow and prevent further integrations from being affected.
May 9, 2026, 00:40 UTC: The affected integrations were identified, and impacted customers were notified that re-authentication was required to restore them.

Root Cause
The issue was triggered by a temporary interruption in our internal update process. During a routine renewal of access credentials, a brief disruption in the processing system prevented the newly issued credentials from being saved successfully. Because the previous credentials were automatically retired by GitLab as part of the standard security workflow — the moment the new credentials were issued — the affected integrations were left without a valid credential. As the credential was no longer valid and could not be recovered from our end, these integrations could not be restored automatically and required the customer to re-authenticate.

Actions Taken
Stabilized the internal update workflow to prevent further integrations from being affected.
Identified the affected integrations and notified the impacted customers that re-authentication was required.
All affected customers re-authenticated their integrations, fully restoring normal syncing.
Verified that all previously synced data remained intact and secure.

Action Items
Improve monitoring to detect similar processing issues in the update workflow more quickly.
Make credential renewal resilient so a newly issued credential is reliably saved as part of the same operation, and so any save failure is detected immediately — eliminating the window where a renewed credential can be lost and an integration is left unrecoverable.
Optimize the processing system to better handle temporary fluctuations in activity. Affected components
 <ul>
 <li>US Environment (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
<li>EU Environment (Operational)</li>
 </ul>

GitLab Integration — Connection Issue [US]

Status: Resolved Summary

On May 5, 2026, customers in the EU region experienced issues with Custom Dashboards not loading as expected, and some filtering/grouping actions were slower than usual on the Violations page. The issue was caused by a configuration update that included an invalid setting, which prevented the EU analytics data service from operating normally. The service was restored the same evening, and we confirmed no data was lost.

Key Timeline (IDT)

May 5, 2026, 16:51 IDT – A configuration update was deployed to the EU production environment.
May 5, 2026, 19:06 IDT – Monitoring detected availability issues and alerts were triggered.
May 5, 2026, 19:23 IDT – Investigation began.
May 5, 2026, 19:36 IDT – The invalid configuration was identified and confirmed as the cause.
May 5, 2026, 19:40 IDT – A controlled recovery approach was planned to ensure data integrity throughout remediation.
May 5, 2026, 19:50 IDT – Additional safeguards and validation steps were performed prior to remediation, including recovery validation in a non-production environment.
May 5, 2026, 21:45 IDT – A safe recovery procedure was confirmed.
May 5, 2026, 22:05 IDT – Production service was recovered and data accessibility was confirmed.

Root Cause

A configuration update introduced an invalid resource value. While the change initially appeared to apply successfully, it caused repeated failures in the automated update process responsible for keeping the service healthy. After continuing to fail, the process removed the running service components associated with the EU analytics service, leading to service unavailability for customers until restoration was completed.

Actions Taken

• Investigated alerts and isolated the problematic configuration change.
• Performed additional safeguards and validation steps prior to remediation.
• Validated recovery steps in a non-production environment before applying them in production.
• Restored service by safely reattaching existing storage and returning processing to normal operation.
• Confirmed service availability and verified that data remained intact.

Action Items

• Add stronger pre-deployment validation to catch malformed configuration values before rollout.
• Improve monitoring and alerting to detect repeated update failures and destructive actions earlier.
• Implement safeguards to prevent automated update workflows from removing stateful resources for this analytics service during invalid update scenarios.
• Improve operational logging and visibility to speed up diagnosis during similar events.
• Expand and regularly validate backup/restore coverage for the affected analytics stateful components. Affected components
 <ul>
 <li>EU Environment (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>US Environment (Operational)</li>
 </ul>

Partial Service Disruption in EU Environment

Status: Resolved A fix supporting both the old and new formats was deployed at 13:00 IST. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
 </ul>

GitLab Webhook Processing Failure Due to Time Format Change

Status: Resolved The incident has been resolved. Affected components
 <ul>
 <li>API (EU Environment) (Operational)</li>
<li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
 </ul>

Short service interruption

Status: Resolved The incident has been resolved. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
 </ul>

Slow CLI scans

Status: Resolved Summary
Between April 10 and April 14, 2026, some customers saw SAST scans and findings generated for branches that were not included in their configured branch-scanning settings. This resulted in unexpected findings, including duplicates and false positives, appearing in the product. The issue was caused by a recent update to the branch-scanning control logic that did not correctly apply customers’ branch configuration during that period. The scanning behavior was corrected on April 14, 2026, and the incident was fully resolved on April 27, 2026 after the unintended findings were removed.

Key Timeline (IDT)

• April 10, 2026, 09:33 IDT — A production update introduced incorrect handling of branch-scanning configuration for some SAST events.
• April 14, 2026, 13:48 IDT — A subsequent update restored expected enforcement of configured branch-scanning rules.
• April 21, 2026, 19:00 IDT — Customer reports alerted us to unexpected SAST findings on non-configured branches.
• April 22, 2026, 13:52 IDT — Root cause identified; scope assessment initiated.
• April 23, 2026, 18:13 IDT — Impact analysis tooling executed to identify affected data and tenants.
• April 27, 2026, 14:30 IDT — Cleanup completed; unintended findings removed and incident fully remediated.

Root Cause
A product update introduced an issue in the branch-scanning configuration check, causing the system to create SAST scans for branches outside of customer-defined scanning rules for a limited period (April 10–14). These extra scans produced unintended findings, which became visible to customers as additional or duplicate items.

Actions Taken

1. Restored correct enforcement of customers’ configured branch-scanning rules.
2. Assessed the scope of the impact across affected environments.
3. Removed unintended SAST findings created for non-configured branches.
4. Confirmed expected behavior after cleanup.

Action Items

1. Improve validation and safeguards around branch-scanning configuration checks during updates.
2. Enhance monitoring to detect unexpected increases in scan volume or findings.
3. Strengthen release checks for feature-gated behavior to prevent similar regressions. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
 </ul>

Increase SAST violations

Status: Resolved Summary
Customers may have experienced general slowness when performing CLI scans across all scan types. This issue was caused by a bug in a newly introduced feature that impacted the efficiency of the scan processing queue. The underlying issue has been identified and resolved, and all scan services have returned to their expected performance levels.

Key Timeline (IDT)

• 14.04.2026, 14:20 IDT: General slowness was observed across all CLI scan types.
• 14.04.2026, 15:40 IDT: The root cause was identified as a processing imbalance within a recently introduced feature.
• 14.04.2026 17:00 IDT: A corrective update was deployed, and the processing environment was restarted.
• 14.04.2026 17:20 IDT: The issue was confirmed as resolved, and scan processing speeds returned to normal.



Root Cause
The slowness was caused by a load balancing issue within a new update process. This resulted in the vast majority of traffic being directed to a single processing resource rather than being distributed evenly. This concentration of traffic led to temporary database connectivity delays and a slowdown in the processing queue, which became visible to customers as delayed scan results.

Actions Taken

• Restarted the processing deployment to clear the bottleneck and restore immediate service.
• Strengthened the load balancing algorithm to ensure traffic is distributed correctly across all available resources.
• Verified that all scan types, including SAST scans, are processing at expected speeds.



Action Items

• Improve the traffic distribution logic to prevent similar resource congestion in the future.
• Enhance monitoring and alerting to detect uneven processing loads more quickly.
• Add additional safeguards to the update process to ensure new features do not impact overall system performance. Affected components
 <ul>
 <li>Application/UI (US Environment) (Operational)</li>
<li>API (US Environment) (Operational)</li>
<li>Application/UI (EU Environment) (Operational)</li>
<li>API (EU Environment) (Operational)</li>
 </ul>

Is Cycode down?

Cycode status is UP

Lastest published events

Infrastructure Provisioning Delays

Issues with Violations and Custom Dashboards (Prod-US)

SAST, SCA and Secret scans slowness

Cycode Services, Components and Regions

Recent Cycode events

Infrastructure Provisioning Delays

Issues with Violations and Custom Dashboards (Prod-US)

SAST, SCA and Secret scans slowness

Degraded performance in on demand scans

Degraded performance in on demand scans

Slow SAST PR scans

Get your FREE account now,
5 monitors included!

Is Cycode down?

Cycode status is UP

Lastest published events

Infrastructure Provisioning Delays

Issues with Violations and Custom Dashboards (Prod-US)

SAST, SCA and Secret scans slowness

Cycode Services, Components and Regions

Recent Cycode events

Infrastructure Provisioning Delays

Issues with Violations and Custom Dashboards (Prod-US)

SAST, SCA and Secret scans slowness

Degraded performance in on demand scans

Degraded performance in on demand scans

Slow SAST PR scans

Get your FREE account now,5 monitors included!

Get your FREE account now,
5 monitors included!