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 · февраль 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.
Мы расследуем проблему, вызывающую переработку старых событий. ** Воздействие:** Некоторые рабочие процессы могут работать снова, что может привести к дублированию предупреждений. PR-сканирование также может быть отложено.
Мы устранили отставание в обработке, вызванное проблемой во время миграции в Кафку. Проблема привела к тому, что старые события были обработаны вместе с новыми событиями, что вызвало задержки и, возможно, обновило некоторые нарушения с устаревшим статусом. Нормальная обработка восстановлена. Тем не менее, клиенты могут по-прежнему видеть некоторые нарушения с устаревшим статусом, пока мы идентифицируем и исправляем затронутые записи. Сканирование PR не задерживалось и не перерабатывалось, а рабочие процессы не затрагивались. Мы продолжаем восстановление и внимательно следим за системой.
Нормальная обработка восстановлена, и инцидент в настоящее время находится на контроле. Небольшое количество клиентов может по-прежнему видеть ограниченное количество нарушений с устаревшим статусом в результате инцидента. Мы определили потенциально затронутые среды и работаем над исправлением затронутых записей.
Система полностью работоспособна. Небольшое количество клиентов может по-прежнему видеть ограниченное количество нарушений с устаревшим статусом в результате инцидента. Мы определили потенциально затронутые среды и работаем над исправлением затронутых записей.
The platform is now fully operational and processing normally
Автоматический перевод официального обновления инцидента.
Команда выявила проблему с ухудшением производительности при сканировании. Могут быть задержки в запуске, запуске и завершении сканирования. Могут быть затронуты все типы сканирования (запросы и CLI). Команда определила проблему с неисправностью при развертывании, и проблема должна быть решена в ближайшее время.
Команда определила первопричину и решила ее. Мы видим, как система возвращается к стабильности.
Теперь система вернулась к полной эксплуатации.
**Корневая причина** Инцидент был вызван развертыванием одной службы, которая управляла миграцией базы данных. Команда определила, что эта миграция содержала неправильный код и в результате приводила к перегрузке базы данных при попытке развертывания службы. В результате служба была частично отключена до тех пор, пока развертывание не было восстановлено. За это время все сканы были обработаны с более низкой, чем ожидалось, производительностью.
Автоматический перевод официального обновления инцидента.
Компонент GitHub: запросы API Оригинальное название: Https://stspg.io/vr201n49yl53
Компонент GitHub: запросы API Оригинальное название: Https://stspg.io/vr201n49yl53
Автоматический перевод официального обновления инцидента.
Обсуждение GitHub: Pull Requests Оригинальное название: https://stspg.io/sm1tp7kfm4vj
Обсуждение GitHub: Pull Requests Оригинальное название: https://stspg.io/sm1tp7kfm4vj
Обсуждение GitHub: Pull Requests Оригинальное название: https://stspg.io/sm1tp7kfm4vj
Автоматический перевод официального обновления инцидента.
Мы заметили ухудшение производительности при сканировании IaC Pull Request. Мы устраняем проблему.
Мы определили первопричину медлительности и принимаем контрмеры.
Отставание, которое привело к замедлению, почти закончилось. Мы следим за ситуацией.
Вопрос решен, и мы продолжаем следить за ситуацией.
Автоматический перевод официального обновления инцидента.
Компонент GitHub: запросы API, запросы Pull Оригинальное название: Https://stspg.io/j5c80shxqm53
GitHub component: API Requests, Pull Requests Original GitHub incident: https://stspg.io/j5c80shxqm53
Автоматический перевод официального обновления инцидента.
Компонент GitHub: Webhooks Оригинальное название: https://stspg.io/syhr80rth84z
Компонент GitHub: Webhooks, Pull Requests Оригинальное название: https://stspg.io/syhr80rth84z
Компонент GitHub: Webhooks, Pull Requests Оригинальное название: https://stspg.io/syhr80rth84z
Автоматический перевод официального обновления инцидента.
В **1:41** PM EDT мы выявили проблему, вызывающую повышенные показатели ошибок при обработке запросов в интерфейсе платформы. Проблема была быстро решена, и в настоящее время платформа работает нормально. Наша команда продолжает активно следить за платформой для обеспечения стабильности сервиса.
Инцидент был урегулирован, и платформа работает в штатном режиме.
Автоматический перевод официального обновления инцидента.
Мы заметили, что часть сканирования CLI Secrets не работает. Мы активно устраняем проблему.
Мы установили, что в CLI версии 3.17.1 введено некорректное поведение. Уничтожение версии CLI до 3.17.0 должно временно решить проблему, пока мы продолжаем понимать и устранять первопричину.
Было применено исправление и полностью восстановлена функциональность, мы продолжаем следить за тем, чтобы все оставалось стабильным.
Автоматический перевод официального обновления инцидента.
Из-за увеличения нагрузки на сканирование мы наблюдали задержки в обновлении статуса нарушения, которое включает автоматическое разрешение нарушений. Источник внезапного увеличения был смягчен, и задержка уже уменьшается. Мы будем следить за ситуацией, пока не вернёмся к нормальной жизни
Мы продолжаем отслеживать процесс обнаружения и связанные с этим задержки в обновлении статуса нарушения (включая автоматическое разрешение)
Автоматический перевод официального обновления инцидента.
Мы заметили ухудшение производительности в нескольких компонентах системы. Мы идентифицируем все пораженные компоненты и идентифицируем первопричину.
Мы заметили ухудшение производительности в нескольких компонентах пользовательского интерфейса приложения. Сканирование, а также Pull Request и CLI также могут быть затронуты.
Мы наблюдаем повышенные показатели тайм-аута Redis. Мы расширяем возможности кластера Redis, чтобы смягчить последствия и восстановить стабильные показатели обслуживания
Регион восстановился и работает в штатном режиме. Мы внимательно следим за работой системы, чтобы обеспечить постоянную стабильность
Сейчас система полностью функционирует. Больше не должно быть ухудшения производительности. ** Резюме** Мы наблюдали период медлительности и периодических тайм-аутов, влияющих на различные системные функции в регионе ЕС, включая интерфейс приложения и сканирование запроса (PR). Проблема была вызвана прежде всего тем, что система обработки данных достигла пределов пропускной способности сети и памяти, что усугублялось большим объемом автоматизированной деятельности из одного источника. С тех пор мы модернизировали базовую инфраструктуру и внедрили меры предосторожности, чтобы предотвратить воздействие подобной крупномасштабной деятельности на систему. В настоящее время проблема полностью решена, и все службы вернулись к ожидаемому уровню производительности. **Key Timeline (IDT)** ** 13 июля 2026 года, 11:44 IDT**: Инцидент обнаружен после сообщений о замедлении пользовательского интерфейса и задержках PR-сканирования. ** 13 июля 2026 года, 12:19 IDT**: Выявлено узкое место инфраструктуры; принято решение об обновлении кластера обработки. ** 13 июля 2026 года, 12:26 IDT**: Был выявлен и отключен автоматизированный процесс большого объема для снижения непосредственной нагрузки. ** 13 июля 2026 года, 13:09 IDT**: Обновление инфраструктуры завершено, пропускная способность сети вернулась к нормальному уровню. ** 13 июля 2026, 15:35 IDT**: Все отставания были устранены, и инцидент был официально разрешен. **Корневая причина** Инцидент был спровоцирован комбинацией факторов: кластер обработки достиг максимальной пропускной способности сети и емкости памяти из-за малогабаритной конфигурации текущей рабочей нагрузки. Это было еще более напряженным из-за конкретного автоматизированного рабочего процесса, который генерировал необычно большой объем запросов на обновление. Кроме того, разница в конфигурации конвейера обработки сообщений в регионе ЕС не позволила системе эффективно справиться с возникшим отставанием. ** Действия, предпринятые** ** Модернизированная инфраструктура**: Кластер обработки был обновлен до типа экземпляра с более высокой емкостью, чтобы обеспечить большую пропускную способность сети и память. ** Инвалидный источник большого объема**: для восстановления стабильности системы временно отключен конкретный идентификатор клиента, ответственный за чрезмерный трафик. ** Восстановленное подключение**: затрагиваемые сервисные компоненты были перезапущены для обеспечения восстановления чистых соединений с модернизированной инфраструктурой. ** Повышенный параллелизм обработки**: Количество разделов в затрагиваемой очереди сообщений было увеличено, чтобы система могла быстрее обрабатывать отставание. ** Пункты действия** • Улучшение мониторинга: Внедрение новых предупреждений для использования сети и памяти для выявления проблем с пропускной способностью, прежде чем они повлияют на клиентов. ** Оптимизируйте рабочий процесс обновления**: Рефакторировать процесс обновления статуса на пакетные запросы, значительно снижая нагрузку на систему обработки. ** Ограничение скорости внедрения**: введение мер предосторожности для предотвращения потребления непропорциональных системных ресурсов из одного источника. **Региональная конфигурация**: Проведение аудита для обеспечения согласованности параметров инфраструктуры и очереди сообщений во всех регионах.
Автоматический перевод официального обновления инцидента.
Мы выявили проблему, которая может привести к ** неточному количеству нарушений** в ** некоторых** приборных панелях продуктов и пользовательских панелях приборной панели, которые полагаются на данные о нарушениях (не все приборные панели затронуты). Мы уже начали коррекционную работу, но потребуется время, чтобы полностью завершить ее, и вы можете увидеть изменения в подсчетах по мере исправления данных. Мы поделимся еще одним обновлением, как только исправление будет завершено и точность данных будет полностью восстановлена.
Мы добились значительного прогресса в исправлении неточных показателей нарушений, влияющих на некоторые продукты и пользовательские панели инструментов. ** Текущий статус:** Для подавляющего большинства учетных записей исправление успешно завершено, а полная точность данных восстановлена. ** Следующие шаги:** Мы активно решаем вопрос по небольшому числу оставшихся затронутых счетов.
Функциональность полностью восстановлена, мы продолжаем следить за тем, чтобы все оставалось стабильным.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем проблему, затрагивающую Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation и Graph AI Services.
Мы выявили проблему конфигурации брандмауэра, которая повлияла на услуги Maestro AI. Конфигурация обновлена, а пострадавшие службы восстановлены. Мы продолжаем следить за ситуацией и работаем над дальнейшей стабилизацией. Некоторые ухудшенные показатели все еще можно наблюдать, пока мы завершаем дополнительные улучшения.
Вопрос, затрагивающий услуги Maestro AI, решен. Maestro Risk Explorability, Risk AI Remediation, Maestro Remediation и Graph AI теперь доступны и работают нормально. ** Резюме** 9 июля 2026 года клиенты, использующие сервис Maestro в европейской производственной среде, пережили период недоступности сервиса. Проблема началась после обновления конфигурации, которое непреднамеренно изменило региональную маршрутизацию сервиса. Это привело к тому, что система пыталась подключаться по сетевому пути, в котором не было необходимых разрешений, и в регион, где конкретные модели обработки были недоступны. Проблема полностью решена, а обслуживание восстановлено для всех пострадавших клиентов. **Key Timeline (IDT)** ** 9 июля 2026 года, 12:02 IDT:** Инцидент был выявлен, и было начато расследование. ** 9 июля 2026 года, 12:07 IDT:** Публичное уведомление о прекращении обслуживания. ** 9 июля 2026 года, 13:00 IDT:** Применялось исправление конфигурации сети, восстанавливающее первичное подключение. ** 9 июля 2026 года, 13:39 IDT:** Служба была полностью восстановлена после реализации модельных откатов, и инцидент был отмечен как устраненный. **Корневая причина** Прерывание обслуживания было вызвано недавним обновлением процесса аутентификации и настройки. Это обновление привело к конфликту в том, как система определила свой операционный регион. В частности, автоматизированный процесс обновления перекрывает ручные настройки, маршрутизируя трафик в другую региональную конечную точку. Этот новый путь был заблокирован недостающим правилом сетевой безопасности и попытался использовать модель обработки, которая не поддерживалась в этом конкретном регионе, что привело к сбою в обслуживании. ** Действия, предпринятые** ** Восстановление сетевого подключения:** Ручно обновляемые правила сетевой безопасности позволяют обеспечить безопасный трафик через новую региональную конечную точку. ** Реализованная модель Fallbacks:** Система была настроена на использование альтернативных моделей обработки для обеспечения немедленной доступности услуг при корректировке долгосрочных региональных конфигураций. ** Обновленная информация о статусе:** Поддерживать обновления в режиме реального времени для заинтересованных сторон и клиентов на протяжении всего процесса восстановления. ** Пункты действия** **Стандартная конфигурационная прецедентность:** Обновите рабочий процесс развертывания, чтобы предотвратить бесшумное превышение автоматизированных процессов над критическими настройками среды. ** Аудит инфраструктуры:** Провести всесторонний обзор правил сетевой безопасности во всех регионах, чтобы обеспечить согласованность и предотвратить аналогичные пробелы в подключении. ** Автоматический мониторинг:** Внедрить комплексные проверки здоровья и синтетические зонды для автоматического выявления региональных проблем с подключением, прежде чем они повлияют на пользователей. **Улучшение политики развертывания:** Установите новые руководящие принципы для обеспечения того, чтобы изменения конфигурации развертывались и валидировались в производственных средах чаще, чтобы снизить риск «постоянных» обновлений.
Автоматический перевод официального обновления инцидента.
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.
** Расследование - Проблемы с нарушениями и пользовательскими панелями (Prod-US)** В настоящее время мы расследуем проблему в нашей среде, где нарушения не загружаются. В результате пользовательские панели приборной панели, которые полагаются на данные о нарушениях, также могут не отображать ошибки. Наша инженерная команда активно изучает первопричину, и мы предоставим здесь обновления, когда узнаем больше. Приносим извинения за неудобства.
Было развернуто исправление проблем, затрагивающих нарушения и пользовательские панели инструментов в Prod-US. Мы активно следим за состоянием окружающей среды, чтобы услуги были полностью восстановлены.
Основная проблема решена, и нарушения и пользовательские панели управления теперь должны работать как обычно. Наша команда активно отслеживает синхронизацию данных, чтобы устранить любые оставшиеся несоответствия с новыми нарушениями. Мы предоставим окончательное обновление после завершения синхронизации.
Мы продолжаем следить за процессом синхронизации данных для новых нарушений в пользовательском интерфейсе. Несмотря на то, что функциональность восстановлена, может потребоваться до 6 часов, чтобы все последние данные полностью догнали и точно отражали. Мы предоставим окончательное обновление после завершения синхронизации.
Синхронизация данных завершена, и все недавние нарушения успешно заселили в пользовательском интерфейсе. Нарушения и пользовательские панели приборов функционируют нормально, и инцидент полностью устранен. Мы ценим ваше терпение, поскольку мы работали над восстановлением полного сервиса.
Функциональность полностью восстановлена, мы продолжаем следить за тем, чтобы все оставалось стабильным.
Автоматический перевод официального обновления инцидента.
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