Cycode Status

The issue was resolved. The system is fully stable now

**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.

# 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.

https://status.gitlab.com/

The incident has been resolved. We will provide the RCA shortly.

**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.

**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.

The system is now fully stable

**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.

No update message available.