История сбоев Cycode

1. 27 октября 2026 г. в 10:06 UTCinvestigating

   ** Резюме** Некоторые интеграции Bitbucket Cloud, которые используют OAuth, отключены после того, как служба аутентификации Bitbucket вернула ошибки 27 октября 2026 года в 03:45 UTC. ** Воздействие** Для затронутых интеграций Cycode не может получить доступ к Bitbucket. Сканирование, синхронизация репозитория и присвоение статусов для этих рабочих пространств прекращаются до тех пор, пока интеграция не будет разрешена снова. Интеграции, которые используют пароли приложений, токены API или токены доступа к рабочему пространству, не затрагиваются. ** Последнее обновление** Наше расследование показывает, что Bitbucket выпустила новые учетные данные для этих интеграций, но не доставила их в Cycode, потому что его служба вернула ошибку. Bitbucket больше не принимает предыдущие учетные данные, поэтому интеграция не может восстановиться автоматически. Мы сообщаем об этом Atlassian. ** Необходимые действия** Если ваша интеграция Bitbucket отображается как отключенная, авторизуйте ее снова в консоли Cycode под [Настройки > Интеграции > Bitbucket]. Цикод продолжается там, где он остановился, и никаких других изменений не требуется. Мы будем публиковать обновления, когда у нас будет больше информации.

2. 27 октября 2026 г. в 10:46 UTCmonitoring

   Мы определили каждую затронутую интеграцию и теперь напрямую связываемся с их пользователями. Интеграция начинает работать снова, как только пользователь снова авторизует ее в консоли Cycode под [Настройки > Интеграции > Bitbucket]. Мы сообщили об ошибке Bitbucket в Atlassian и опубликуем обновление, когда у нас будет больше информации.

3. 27 октября 2026 г. в 12:51 UTCresolved

   Все затронутые интеграции Bitbucket Cloud были идентифицированы, и их пользователи получили инструкции для их авторизации. Интеграции, которые были разрешены, работают нормально. Основной причиной стала ошибка сервиса Bitbucket 27 октября 2026 года в 03:45 UTC, которая аннулировала учетные данные некоторых интеграций. Мы поделились подробностями с Atlassian для их расследования.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 09:28 UTCinvestigating

   Мы определили потенциальную причину проблем с потоком входа в систему и продолжаем расследование.

2. 20 октября 2026 г. в 09:54 UTCinvestigating

   Мы решили проблему логина в регионе ЕС.

3. 20 октября 2026 г. в 10:04 UTCmonitoring

   Проблема решена, и мы продолжаем следить за системой, чтобы обеспечить стабильность.

4. 20 октября 2026 г. в 15:43 UTCresolved

   Инцидент полностью урегулирован, дальнейших вопросов мы не видим.

Автоматический перевод официального обновления инцидента.

1. 18 октября 2026 г. в 13:10 UTCinvestigating

   Мы изучаем ошибки в приложении, связанные со сканированием PR и нарушениями нагрузки. Мы будем продолжать публиковать дальнейшие обновления, как только мы найдем причину.

2. 18 октября 2026 г. в 13:26 UTCidentified

   У нас была проблема с одной из наших баз данных приложений. База данных вернулась к нормальной работе, но все еще деградирует, и мы активно работаем над ее исправлением. Платформа вернулась к нормальной работе, а нарушения и PR-сканирование должны работать нормально.

3. 18 октября 2026 г. в 13:34 UTCmonitoring

   База данных возвращается к нормальной работе. Мы активно следим за тем, чтобы не осталось никаких проблем.

4. 18 октября 2026 г. в 14:40 UTCresolved

   Инцидент полностью урегулирован, дальнейших вопросов мы не видим.

Автоматический перевод официального обновления инцидента.

1. 13 октября 2026 г. в 12:56 UTCmonitoring

   **Мониторинг**: сканирование API (регион США) Ранее сегодня наша система оповещения обнаружила, что сервис, стоящий за API-интерфейсом сканирования, перезагружается чаще, чем ожидалось, что привело к неисправности некоторых запросов в течение короткого периода времени. Мы увеличили объем памяти, доступной для сервиса, и с тех пор она остается стабильной. Мы держим службу под пристальным наблюдением, пока мы завершаем постоянное улучшение.

2. 13 октября 2026 г. в 13:01 UTCresolved

   **Решение**: Краткое замедление API сканирования (регион США) 13 октября 2026 года, между 07:58 и 08:28 UTC, некоторые запросы Сканирование API в регионе США провалилось или было медленным. Сканирование страниц в пользовательском интерфейсе Cycode и CLI Cycode, возможно, показало временные ошибки, и некоторые сканы запроса на вытягивание пришли на несколько минут позже, чем обычно. Мы увеличили доступную сервису память, что полностью разрешило проблему в 08:34 UTC. Все очередей сканирования завершились вскоре после этого, и никаких данных не было потеряно. Мы определили причину, и постоянное улучшение находится на рассмотрении.

Автоматический перевод официального обновления инцидента.

1. 13 октября 2026 г. в 08:30 UTCinvestigating

   В настоящее время GitLab испытывает сбои в обслуживании, которые могут повлиять на сканирование и интеграцию Cycode PR. Проблема исходит из инфраструктуры GitLab и находится вне контроля Cycode. Мы отслеживаем ситуацию и будем предоставлять обновления, поскольку GitLab работает над восстановлением нормального обслуживания. Для получения дополнительной информации, пожалуйста, обратитесь к странице статуса GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614] (https://status.gitlab.com/pages/5b36dc6502d06804c083f7/6acdd94de3aa7005ae52c614)

2. 13 октября 2026 г. в 08:47 UTCmonitoring

   GitLab перенес инцидент, влияющий на PR-сканирование и интеграционную связь, на этап мониторинга. GitLab внедрила исправление и отслеживает результаты. Мы продолжаем отслеживать влияние на интеграцию Cycode и при необходимости будем предоставлять дополнительные обновления. Для получения дополнительной информации, пожалуйста, обратитесь к странице статуса GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614] (https://status.gitlab.com/pages/5b36dc6502d06804c083f7/6acdd94de3aa7005ae52c614)

3. 13 октября 2026 г. в 11:27 UTCresolved

   GitLab устранил инцидент, влияющий на PR-сканирование и интеграционную связь

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:22 UTCinvestigating

   The team continues to work with AWS, which escalated the issue internally. In parallel, we are working to restore functionality by moving to another database. Any blocked pull requests waiting for Cycode status can be unblocked by removing Cycode scans from expected checks directly in your SCM (Source Code Management). Reach out to Your Cycode representative to help with streamlining the process.

2. 7 октября 2026 г. в 14:22 UTCinvestigating

   AWS has confirmed that the affected PostgreSQL instance is currently in an internal recovery state. The expected Multi-AZ failover did not occur as designed, and AWS is actively investigating why. In parallel, we are continuing work to restore the affected services using an alternative database path to accelerate recovery

3. 7 октября 2026 г. в 14:22 UTCinvestigating

   We are seeing database is restoring its operational capabities. We see first Pull Request scans being processed. We are monitoring the system and increasing the throughput.

4. 7 октября 2026 г. в 14:22 UTCinvestigating

   Database remains fully operational. We are working on increasing processing speed beyond regular to process all backlogs as soon as possible.

5. 7 октября 2026 г. в 14:22 UTCinvestigating

   We’re continuing to investigate a major degradation in the US platform caused by PostgreSQL connection exhaustion. Customers may experience slow response times, elevated 500 errors, and slower PR workflows and CLI scans. We’ve reduced database load across several services and initiated an RDS failover. The team is actively working to restore normal performance.

6. 7 октября 2026 г. в 14:22 UTCinvestigating

   We have noticed degraded performance in prod-us Flows like Pull Request or CLI scanning can be slower than usual

7. 7 октября 2026 г. в 14:22 UTCinvestigating

   The team is actively working with AWS and investigating what appears to be a database failover issue affecting the US environment. We’ll share another update as soon as we have more information.

8. 7 октября 2026 г. в 14:22 UTCinvestigating

   The US platform is improving following the earlier RDS/PostgreSQL connection exhaustion. AWS has confirmed that the original PostgreSQL instance has returned to an operational state, and we’re seeing PR scans being processed again. The main remaining degradation is delayed GitHub-driven processing due to a large webhook backlog, which is continuing to drain. We’ll continue monitoring recovery and provide another update as processing returns to normal

9. 7 октября 2026 г. в 14:22 UTCinvestigating

   The system is back to being fully operational

10. 7 октября 2026 г. в 14:22 UTCresolved

    (2/2) • Paused the workloads that were creating high volumes of short-lived data operations, to reduce database load while delayed events cleared. • Scanned the pull requests that were missed during the incident. **4b. Action Items** • Change how large batches of data are written to reduce database load. • Move our highest-volume workload to its own dedicated database, so a problem there can't affect the rest of the platform. • Add alerts and deeper monitoring for database connection usage and database health. • Give each service its own dedicated database credentials. • Process incoming events more efficiently to speed up recovery after a disruption. • Improve monitoring of processing delays and of internal event alerts. • Review database capacity and performance settings to add more headroom.

11. 7 октября 2026 г. в 14:22 UTCresolved

    (1/2) **1. Summary** On October 5, 2026, starting at 15:55 IDT, customers on our US platform saw slow responses, intermittent errors, and delays in pull request checks and CLI scans. Some customers whose repositories require Cycode pull request checks couldn't merge until scanning resumed. The issue started when a background maintenance process in our primary database fell behind and stopped completing, and the database stopped saving new data. Restoring service took several hours because the standby database first had to process a large backlog of changes. The database was back and the platform was available again by 19:43 IDT. Delayed processing then caught up, and the incident was resolved at 23:24 IDT. Pull requests that were missed during the incident were scanned. **2. Key Timeline (IDT)** • **October 5, 2026, 12:55 IDT**: A routine database maintenance process starts running much slower than normal. No customer impact yet. • **October 5, 2026, 14:53 IDT**: The next maintenance cycle starts and doesn't complete. • **October 5, 2026, 15:55 IDT**: The database stops saving new data, and platform performance degrades. • **October 5, 2026, 16:03 IDT**: The database reaches its connection limit. Customers start seeing errors. • **October 5, 2026, 16:21 IDT**: Incident declared and response team engaged. • **October 5, 2026, 16:24 IDT**: First update posted to the status page. • **October 5, 2026, 16:49 IDT**: Switch to the standby database started. • **October 5, 2026, 17:00 IDT**: Support case opened with our cloud infrastructure provider. • **October 5, 2026, 18:24 IDT**: Alternative recovery path started in parallel. Workaround published for customers blocked by required pull request checks. • **October 5, 2026, 19:43 IDT**: Database available again, and the Cycode API and Cycode Platform are accessible. • **October 5, 2026, 19:54 IDT**: Pull request scanning resumes. • **October 5, 2026, 20:20 IDT**: Processing capacity increased to clear delayed events. • **October 5, 2026, 20:45 IDT**: High-volume workloads paused to reduce database load. • **October 5, 2026, 21:56 IDT**: Pull requests missed during the incident identified and scanned. • **October 5, 2026, 23:09 IDT**: All services fully operational. • **October 5, 2026, 23:24 IDT**: Incident resolved. **3. Root Cause** Our database runs a routine background process that regularly saves recent changes to permanent storage. Two conditions contributed to that process slowing down: • **High-volume short-lived data operations:** some of our processing workloads were constantly creating and removing large numbers of short-lived data structures. • **A delayed background sync:** a data-sync process had fallen far behind, which stopped the database from cleaning up after itself. The maintenance process slowed down and eventually stopped completing. The database could then no longer save new data, and requests started to queue. Our services retried those requests and opened many new connections, which used up the database's connection capacity. Customers saw this as errors and slow responses. We switched to our standby database. Before it could serve traffic, it had to process all changes made since the last completed maintenance cycle, about four hours of activity. That extended the outage. **4. Actions Taken** • Reduced load on the database by temporarily scaling down non-essential processing. • Started a switch to the standby database. • Opened a support case with our cloud infrastructure provider and worked with them on an escalated basis. • Prepared an alternative recovery path in parallel. • Shared a temporary workaround for customers blocked by required pull request checks. • Once the database recovered, increased processing capacity to clear delayed events.

12. 7 октября 2026 г. в 14:22 UTCinvestigating

    Last remaining backlog continues being processed at a steady rate. Our estimations show that last parts backlog should be fully processed in about 60-90 minutes (20:30 UTC). We see the majority of pull request scans (60% at the moment of this update) are being completed in below 15 minutes. and this number is constantly growing at a steady rate. Other than that system looks operational. We believe application/UI are fully operational.

1. 5 октября 2026 г. в 13:24 UTCinvestigating

   Мы заметили ухудшение производительности в prod-us Потоки, такие как Pull Request или CLI, могут быть медленнее, чем обычно

2. 5 октября 2026 г. в 14:17 UTCinvestigating

   Мы продолжаем исследовать серьезное ухудшение на американской платформе, вызванное истощением соединения PostgreSQL. Клиенты могут испытывать медленное время отклика, повышенные 500 ошибок и более медленные рабочие процессы PR и сканирование CLI. Мы сократили нагрузку на базы данных в нескольких службах и инициировали отказ от RDS. Команда активно работает над восстановлением нормальной работы.

3. 5 октября 2026 г. в 14:29 UTCinvestigating

   Команда активно работает с AWS и исследует то, что, по-видимому, является проблемой отказа базы данных, затрагивающей окружающую среду США. Мы поделимся еще одним обновлением, как только у нас будет больше информации.

4. 5 октября 2026 г. в 15:17 UTCinvestigating

   Команда продолжает работать с AWS, что обострило проблему внутри компании. Параллельно мы работаем над восстановлением функциональности путем перехода на другую базу данных. Любые заблокированные запросы на извлечение, ожидающие статуса Cycode, могут быть разблокированы путем удаления сканирования Cycode из ожидаемых проверок непосредственно в вашем SCM (Управление исходным кодом). Обратитесь к своему представителю Cycode, чтобы помочь с оптимизацией процесса.

5. 5 октября 2026 г. в 16:10 UTCinvestigating

   AWS подтвердила, что пострадавший экземпляр PostgreSQL в настоящее время находится в состоянии внутреннего восстановления. Ожидаемый отказ от Multi-AZ произошел не так, как планировалось, и AWS активно исследует, почему. Параллельно мы продолжаем работу по восстановлению пострадавших сервисов, используя альтернативный путь базы данных для ускорения восстановления

6. 5 октября 2026 г. в 16:58 UTCinvestigating

   Мы видим, что база данных восстанавливает свои оперативные возможности. Мы видим, как обрабатываются первые сканы Pull Request. Мы следим за системой и увеличиваем пропускную способность.

7. 5 октября 2026 г. в 17:31 UTCinvestigating

   База данных остается полностью работоспособной. Мы работаем над увеличением скорости обработки сверх обычной, чтобы как можно скорее обработать все отставания.

8. 5 октября 2026 г. в 18:17 UTCinvestigating

   Американская платформа улучшается после более раннего исчерпания соединения RDS / PostgreSQL. AWS подтвердила, что оригинальный экземпляр PostgreSQL вернулся в рабочее состояние, и мы снова видим, как обрабатываются PR-сканирования. Основной оставшейся деградацией является задержка обработки на GitHub из-за большого отставания веб-хуков, которое продолжает истощаться. Мы будем продолжать следить за восстановлением и предоставлять еще одно обновление, поскольку обработка возвращается к нормальному состоянию

9. 5 октября 2026 г. в 19:06 UTCinvestigating

   Последнее оставшееся отставание продолжает обрабатываться с постоянной скоростью. Наши оценки показывают, что последние запчасти должны быть полностью обработаны примерно за 60-90 минут (20:30 UTC). Мы видим, что большинство сканирований запросов на вытягивание (60% на момент обновления) выполняются менее чем за 15 минут. И это число постоянно растет устойчивыми темпами. Кроме того, система выглядит работоспособной. Мы считаем, что приложение/UI полностью работоспособны.

10. 5 октября 2026 г. в 20:09 UTCinvestigating

    Система вернулась к полноценной работе

11. 5 октября 2026 г. в 20:24 UTCresolved

    **1. Резюме** 5 октября 2026 года, начиная с 15:55 IDT, клиенты на нашей американской платформе видели медленные ответы, периодические ошибки и задержки в проверках запросов на вытягивание и сканировании CLI. Некоторые клиенты, чьи репозитории требуют проверки запросов Cycode, не могли объединиться, пока не возобновилось сканирование. Проблема началась, когда процесс фонового обслуживания в нашей основной базе данных отстал и перестал завершаться, а база данных перестала сохранять новые данные. Реставрация заняла несколько часов, потому что резервная база данных сначала должна была обработать большое количество изменений. База данных вернулась, и платформа снова стала доступна к 19:43 IDT. Задержка с обработкой затем догнала, и инцидент был разрешен в 23:24 IDT. Запросы, которые были пропущены во время инцидента, были отсканированы. **2. Ключевые сроки (IDT)** ** 5 октября 2026 года, 12:55 IDT**: Обычный процесс обслуживания базы данных начинает работать намного медленнее, чем обычно. Влияния клиентов пока нет. ** 5 октября 2026 года, 14:53 IDT**: Следующий цикл обслуживания начинается и не завершается. ** 5 октября 2026 года, 15:55 IDT**: База данных перестает сохранять новые данные, а производительность платформы ухудшается. ** 5 октября 2026 года, 16:03 IDT**: База данных достигает своего предела подключения. Клиенты начинают видеть ошибки. ** 5 октября 2026 года, 16:21 IDT**: Объявлено о происшествии и привлечена группа реагирования. ** 5 октября 2026 года, 16:24 IDT**: Первое обновление опубликовано на странице статуса. ** 5 октября 2026 года, 16:49 IDT**: Начался переход на резервную базу данных. ** 5 октября 2026 года, 17:00 IDT**: Случай поддержки открылся у нашего поставщика облачной инфраструктуры. ** 5 октября 2026 года, 18:24 IDT**: Альтернативный путь восстановления начался параллельно. Обработка, опубликованная для клиентов, заблокированных необходимыми проверками запроса на вытягивание. ** 5 октября 2026 года, 19:43 IDT**: База данных снова доступна, а API и платформа Cycode доступны. ** 5 октября 2026 года, 19:54 IDT**: Запрос на сканирование резюме. ** 5 октября 2026 года, 20:20 IDT**: Возможности обработки увеличились, чтобы прояснить отсроченные события. ** 5 октября 2026 года, 20:45 IDT**: Рабочие нагрузки большого объема остановились, чтобы уменьшить нагрузку на базу данных. ** 5 октября 2026 года, 21:56 IDT**: Запросы на вытягивание, пропущенные во время инцидента, идентифицированы и отсканированы. ** 5 октября 2026 года, 23:09 IDT**: Все услуги полностью работоспособны. ** 5 октября 2026 года, 23:24 IDT**: Инцидент разрешен. **3. Коренная причина** Наша база данных запускает обычный фоновый процесс, который регулярно сохраняет последние изменения в постоянном хранилище. Два условия способствовали замедлению этого процесса: ** Высокообъемные операции с кратковременными данными: некоторые из наших рабочих нагрузок на обработку постоянно создавали и удаляли большое количество короткоживущих структур данных. ** Отсроченная фоновая синхронизация: ** процесс синхронизации данных значительно отстал, что не позволило базе данных очиститься после себя. Процесс технического обслуживания замедлился и в конечном итоге прекратился. База данных больше не могла сохранять новые данные, и запросы начали стоять в очереди. Наши службы проверили эти запросы и открыли много новых соединений, которые использовали возможности подключения базы данных. Клиенты восприняли это как ошибки и медленные ответы. Мы перешли на резервную базу данных. Прежде чем он смог обслуживать трафик, он должен был обработать все изменения, внесенные с момента последнего завершенного цикла технического обслуживания, около четырех часов работы. Это продлило отключение. **4 Принятые меры** Снижение нагрузки на базу данных путем временного масштабирования несущественной обработки. • Начался переход на резервную базу данных. Мы открыли дело поддержки с нашим поставщиком облачной инфраструктуры и работали с ним на усиленной основе. • Параллельно подготавливается альтернативный путь восстановления. • Общий временный обходной путь для клиентов, заблокированных необходимыми проверками запроса на вытягивание. После того, как база данных восстановилась, увеличилась способность обработки для устранения задержек. • Приостановил рабочие нагрузки, которые создавали большие объемы операций с кратковременными данными, чтобы уменьшить нагрузку на базу данных, в то время как отложенные события очищались. • Просканированы запросы на вытягивание, которые были пропущены во время инцидента. **4b. Пункты действия** Измените, как большие партии данных пишутся, чтобы уменьшить нагрузку на базу данных. Переместите нашу самую большую рабочую нагрузку в свою собственную специализированную базу данных, чтобы проблема не могла повлиять на остальную часть платформы. • Добавьте оповещения и более глубокий мониторинг для использования подключения к базе данных и здоровья базы данных. • Дайте каждому сервису свои собственные учетные данные базы данных. Обработка входящих событий более эффективно, чтобы ускорить восстановление после сбоя. Улучшение мониторинга задержек обработки и внутренних оповещений о событиях. • Просмотрите возможности базы данных и настройки производительности, чтобы добавить больше залов.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:14 UTCmonitoring

   В 2:00 PM EDT (18:00 UTC) мы выявили значительный всплеск нагрузки, влияющий на базу данных аутентификации. Чтобы смягчить проблему, мы провели обновление экземпляра. Короткое прерывание подключения к базе данных может произойти во время обновления. Платформа стабильна, и мы продолжаем внимательно следить за ситуацией.

2. 7 октября 2026 г. в 14:14 UTCresolved

   Система функционирует в полном объеме, и никаких текущих проблем не наблюдается. Теперь этот инцидент урегулирован.

Автоматический перевод официального обновления инцидента.

1. 28 сентября 2026 г. в 19:08 UTCmonitoring

   В 2:00 PM EDT (18:00 UTC) мы выявили значительный всплеск нагрузки, влияющий на базу данных аутентификации. Чтобы смягчить проблему, мы провели обновление экземпляра. Короткое прерывание подключения к базе данных может произойти во время обновления. Платформа стабильна, и мы продолжаем внимательно следить за ситуацией.

2. 28 сентября 2026 г. в 20:45 UTCresolved

   Система функционирует в полном объеме, и никаких текущих проблем не наблюдается. Теперь этот инцидент урегулирован.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:14 UTCresolved

   Решенный

2. 7 октября 2026 г. в 14:14 UTCinvestigating

   Компонент GitHub: Pull Requests Оригинальный инцидент с GitHub

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 08:42 UTCinvestigating

   Компонент GitHub: Pull Requests Оригинальный инцидент с GitHub

2. 8 октября 2026 г. в 08:42 UTCresolved

   Решенный

Автоматический перевод официального обновления инцидента.

1. 13 сентября 2026 г. в 10:36 UTCinvestigating

   Компонент GitHub: Pull Requests Оригинальный инцидент с GitHub

2. 13 сентября 2026 г. в 18:53 UTCresolved

   Решенный

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:04 UTCresolved

   Показатели MemoryDB стабильны, задержка обработки восстановлена, и система теперь полностью работает.

2. 7 октября 2026 г. в 14:04 UTCmonitoring

   Мы наблюдали резкий всплеск использования памяти MemoryDB в prod-us, включая активное использование свопа. Применяется смягчение. С тех пор показатели MemoryDB остаются стабильными, а задержка обработки быстро уменьшается

3. 7 октября 2026 г. в 14:04 UTCinvestigating

   Мы заметили ухудшение производительности в prod-us Потоки, такие как Pull Request или CLI, могут быть медленнее, чем обычно

Автоматический перевод официального обновления инцидента.

1. 8 сентября 2026 г. в 16:53 UTCinvestigating

   Мы заметили ухудшение производительности в prod-us Потоки, такие как Pull Request или CLI, могут быть медленнее, чем обычно

2. 8 сентября 2026 г. в 17:21 UTCmonitoring

   Мы наблюдали резкий всплеск использования памяти MemoryDB в prod-us, включая активное использование свопа. Применяется смягчение. С тех пор показатели MemoryDB остаются стабильными, а задержка обработки быстро уменьшается

3. 8 сентября 2026 г. в 17:26 UTCresolved

   Показатели MemoryDB стабильны, задержка обработки восстановлена, и система теперь полностью работает.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:14 UTCinvestigating

   Мы заметили ухудшение производительности в prod-eu. Деградация производительности влияет на все приложения, и все потоки (например, Pull Request или CLI-сканирование) могут быть медленнее, чем обычно. Наше первоначальное исследование предполагает чрезмерную нагрузку на общую базу данных, что замедляет чтение и запись. Команда продолжает расследование.

2. 7 октября 2026 г. в 14:14 UTCresolved

   Система вернулась к полноценной работе.

Автоматический перевод официального обновления инцидента.

1. 8 сентября 2026 г. в 09:53 UTCinvestigating

   Мы заметили ухудшение производительности в prod-eu. Деградация производительности влияет на все приложения, и все потоки (например, Pull Request или CLI-сканирование) могут быть медленнее, чем обычно. Наше первоначальное исследование предполагает чрезмерную нагрузку на общую базу данных, что замедляет чтение и запись. Команда продолжает расследование.

2. 8 сентября 2026 г. в 10:52 UTCresolved

   Система вернулась к полноценной работе.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:14 UTCresolved

   Обсуждение GitHub: Pull Requests Оригинальный инцидент GitHub: https://stspg.io/0xbhhq84v4mt

2. 7 октября 2026 г. в 14:14 UTCinvestigating

   Обсуждение GitHub: Pull Requests Оригинальный инцидент GitHub: https://stspg.io/0xbhhq84v4mt

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 08:42 UTCinvestigating

   Обсуждение GitHub: Pull Requests Оригинальный инцидент GitHub: https://stspg.io/0xbhhq84v4mt

2. 8 октября 2026 г. в 08:42 UTCresolved

   Обсуждение GitHub: Pull Requests Оригинальный инцидент GitHub: https://stspg.io/0xbhhq84v4mt

Автоматический перевод официального обновления инцидента.

1. 1 сентября 2026 г. в 15:10 UTCinvestigating

   Обсуждение GitHub: Pull Requests Оригинальный инцидент GitHub: https://stspg.io/0xbhhq84v4mt

2. 1 сентября 2026 г. в 16:05 UTCresolved

   Обсуждение GitHub: Pull Requests Оригинальный инцидент GitHub: https://stspg.io/0xbhhq84v4mt

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 08:42 UTCinvestigating

   Обсуждение GitHub: Pull Requests Оригинальное название: https://stspg.io/nrbwjftcz72

2. 8 октября 2026 г. в 08:42 UTCresolved

   Обсуждение GitHub: Pull Requests Оригинальное название: https://stspg.io/nrbwjftcz72

Автоматический перевод официального обновления инцидента.