История сбоев Circle Ci

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

   Мы обнаружили проблемы с сетью, влияющие на нашу инфраструктуру Mac. Мы расследуем и вскоре предоставим обновления. Клиенты могут испытывать очереди в течение этого времени.

2. 4 сентября 2026 г. в 15:43 UTCidentified

   Мы идентифицировали сетевую проблему с нашим поставщиком инфраструктуры Mac и работаем с ними, чтобы решить эту проблему. Мы начинаем видеть некоторое восстановление, но мы ожидаем, что клиенты все еще могут увидеть некоторые очереди. Скоро мы обновимся.

3. 4 сентября 2026 г. в 16:19 UTCmonitoring

   Наш поставщик инфраструктуры Mac исправил эту сетевую проблему, и мы видим, что время в очереди возвращается к норме. Мы будем продолжать следить за вещами еще некоторое время. Скоро мы обновимся.

4. 4 сентября 2026 г. в 16:55 UTCresolved

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

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

1. 26 августа 2026 г. в 15:43 UTCidentified

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

2. 26 августа 2026 г. в 16:04 UTCmonitoring

   Мы смягчили проблему с использованием API-интерфейсов, и соответствующие страницы в пользовательском интерфейсе загружаются правильно.

3. 26 августа 2026 г. в 16:10 UTCresolved

   Этот инцидент был урегулирован.

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

1. 25 августа 2026 г. в 23:20 UTCresolved

   Между 19:49 UTC и 21:07 UTC 25 августа 2026 года клиенты, пытающиеся войти в CircleCI с помощью GitHub, не смогли войти и получили ошибку от GitHub, заявив, что обратный URL-адрес недействителен. Клиенты, которые уже вошли в систему, не пострадали. Проблема решена, и логин GitHub работает нормально. Мы благодарим вас за терпение, пока наша команда работала над внедрением исправления.

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

1. 17 августа 2026 г. в 21:06 UTCidentified

   Причина проблемы выявлена, и мы работаем над ее устранением.

2. 17 августа 2026 г. в 21:36 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

3. 17 августа 2026 г. в 21:37 UTCresolved

   Данные Insights снова хороши. Спасибо за ваше терпение.

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

1. 17 августа 2026 г. в 14:04 UTCidentified

   GitHub сообщил об инциденте, который влияет на запуск трубопровода CircleCI и вход в систему: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Рабочие места, которые находятся на рейсах, работают, но отчет о статусе в GitHub Pull Requests может потерпеть неудачу.

2. 17 августа 2026 г. в 14:25 UTCidentified

   Мы продолжаем наблюдать высокие показатели ошибок на API GitHub и снижение трафика веб-хуков. Мы будем продолжать предоставлять обновления по мере поступления дополнительной информации.

3. 17 августа 2026 г. в 15:49 UTCidentified

   Мы продолжаем видеть высокие показатели ошибок на API GitHub и снижение трафика веб-хуков. В результате клиенты, использующие GitHub в качестве своей VCS, могут испытать влияние на свою платформу CircleCI. Это напрямую связано с инцидентом, который переживает GitHub: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Мы будем предоставлять обновления по мере поступления дополнительной информации.

4. 17 августа 2026 г. в 16:22 UTCmonitoring

   Мы начали наблюдать улучшение стабильности в API GitHub. Мы будем продолжать следить за их восстановлением.

5. 17 августа 2026 г. в 17:01 UTCmonitoring

   Скорость ошибок и задержки API GitHub, похоже, восстановились. Мы продолжим мониторинг.

6. 17 августа 2026 г. в 17:23 UTCmonitoring

   Некоторые API GitHub все еще деградируют, что приводит к небольшому количеству сбоев, связанных с обновлением статуса и обработкой крючков. Мы будем продолжать делать все возможное, чтобы смягчить эти последствия.

7. 17 августа 2026 г. в 19:05 UTCresolved

   API GitHub работают нормально.

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

1. 15 августа 2026 г. в 13:58 UTCresolved

   После запланированного технического обслуживания, которое закончилось в 13:00 UTC 15 августа, некоторое влияние на обработку работы продолжалось в течение примерно 30 минут за окном, о котором мы объявили. Некоторые клиенты продолжали видеть задержки в начале работы, наряду с небольшим количеством рабочих мест, которые терпели неудачу с ошибками инфраструктуры, примерно до 13:30 UTC. Это было решено, и работа вернулась в нормальное русло. Клиенты, чья работа потерпела неудачу во время этого окна, могут возобновить работу. Мы благодарим вас за терпение, в то время как наша команда работала над внедрением исправления и приносим извинения за любые неудобства, которые могло вызвать длительное воздействие.

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

1. 12 августа 2026 г. в 16:33 UTCidentified

   В настоящее время GitHub переживает деградацию услуг (https://www.githubstatus.com/incidents/76t89hbfb09h). Клиенты, которые используют GitHub в качестве своей VCS, могут в результате повлиять на работу платформы CircleCI, что повлияет на оформление заказа и рабочие процессы. Мы предоставим еще одно обновление, поскольку у нас есть больше информации для обмена. Спасибо за ваше терпение.

2. 12 августа 2026 г. в 16:43 UTCresolved

   The issue impacting customers who use GitHub as their VCS while GitHub was undergoing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h) has now been resolved. GitHub has resolved the underlying issue and the affected functionality has returned to normal. We thank you for your patience.

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

1. 11 августа 2026 г. в 17:42 UTCresolved

   Between 13:50 UTC and approximately 17:30 UTC on August 11, 2026, some customers experienced delays of up to an hour in pipeline status updates and in notification delivery. Between 16:40 UTC and 17:00 UTC within that same window, a small number of customers also saw newly created pipelines fail to process, appearing in an errored state in the UI and API. The issue has been resolved and all affected functionality has returned to normal. Customers whose pipelines errored during that window can retrigger them. We thank you for your patience while our team worked on implementing a fix.

1. 6 августа 2026 г. в 13:06 UTCinvestigating

   Usage API data is delayed for 8/5/2026. All prior data remains available. We are investigating. Thank you for your patience.

2. 6 августа 2026 г. в 15:06 UTCidentified

   The issue has been identified and a fix is in progress.

3. 6 августа 2026 г. в 19:33 UTCmonitoring

   A fix is in place and is being monitored. Thanks for your patience.

4. 6 августа 2026 г. в 19:54 UTCresolved

   The Usage API issue has been resolved. Data has been loaded for yesterday, 8/5/2026. We appreciate your patience.

1. 5 августа 2026 г. в 16:58 UTCinvestigating

   Мы видим проблему с сервисом Insights, где данные за последние 24 часа отстают. Мы проводим расследование.

2. 5 августа 2026 г. в 17:46 UTCinvestigating

   We are continuing to investigate and will update as we know more.

3. 5 августа 2026 г. в 18:25 UTCidentified

   We have identified the issue, and are working with our upstream provider to resolve it now.

4. 5 августа 2026 г. в 21:01 UTCresolved

   The upstream issue has been resolved, and the insights data from the last 24 hours has caught up. Thank you for your patience.

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

1. 4 августа 2026 г. в 19:27 UTCinvestigating

   We are experiencing increased queue times for Windows, Android, and GPU jobs due to capacity constraints with a third-party infrastructure provider. Jobs will continue to be processed but may take longer than usual to start. Thank you for your patience while our engineers work to resolve this.

2. 4 августа 2026 г. в 19:59 UTCmonitoring

   We're starting to see queue times slowly recovering. We'll be monitoring this situation, we appreciate your patience.

3. 4 августа 2026 г. в 20:33 UTCmonitoring

   Queue times continue to gradually recover with our third-party infrastructure provider, though we've seen a slight uptick in the last 30 mins. We're keeping an eye on this and will keep you updated as things get back to normal. Again, thank you for your patience.

4. 4 августа 2026 г. в 21:16 UTCmonitoring

   Queue times for both Android and Windows jobs, which had been recovering, have started to rise again. This continues to be related to capacity constraints with our third-party infrastructure provider. We'll continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

5. 4 августа 2026 г. в 21:46 UTCmonitoring

   Queue times for both Android and Windows jobs continue to be volatile, with sharp swings up and down. This remains related to capacity constraints with our third-party infrastructure provider. Our team will continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

6. 4 августа 2026 г. в 22:20 UTCmonitoring

   Queue times for both Android and Windows jobs, affected by capacity constraints with our third-party infrastructure provider, have been recovering significantly for the last half hour. We're continuing to monitor for a bit longer to confirm they return to normal levels. We appreciate your patience.

7. 4 августа 2026 г. в 23:40 UTCresolved

   Queue times for Android and Windows jobs have reduced significantly over the last hour. You may still notice brief, isolated queuing at times, but this is no longer at incident-level impact. This was related to capacity constraints with a third-party infrastructure provider. We thank you for your patience while we monitored the situation. If you have any issues, please reach out to our Support team.

1. 24 июля 2026 г. в 16:35 UTCidentified

   В настоящее время GitHub переживает деградацию услуг (https://www.githubstatus.com/incidents/yjysg0xrl67m). Клиенты, которые используют GitHub в качестве своей VCS, могут в результате повлиять на работу платформы CircleCI, что повлияет на оформление заказа и рабочие процессы. Мы предоставим еще одно обновление, поскольку у нас есть больше информации для обмена. Спасибо за ваше терпение.

2. 24 июля 2026 г. в 17:41 UTCresolved

   Проблема, затрагивающая клиентов, использующих GitHub в качестве VCS, в то время как GitHub подвергался деградации услуг (https://www.githubstatus.com/incidents/yjysg0xrl67m), в настоящее время решена. GitHub решил основную проблему, и функциональность вернулась в нормальное состояние. Мы благодарим вас за терпение.

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

1. 22 июля 2026 г. в 19:57 UTCinvestigating

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

2. 22 июля 2026 г. в 23:17 UTCinvestigating

   Мы продолжаем исследовать повышенное время ожидания, затрагивающее клиентов, использующих машинные исполнители поколения 3. Пострадавшие рабочие места могут занять больше времени, чем обычно, чтобы начать. Мы предоставим еще одно обновление, как только у нас будет больше информации для обмена.

3. 23 июля 2026 г. в 00:31 UTCinvestigating

   Мы определили проблему и работаем с нашим поставщиком, чтобы решить проблему доступности ресурсов поколения 3. Гены 1 и 2 полностью работоспособны.

4. 23 июля 2026 г. в 02:05 UTCresolved

   Между 19:24 UTC 22 июля и 01:50 UTC 23 июля клиенты, использующие классы ресурсов превью-машины gen3 (Linux VM), испытывали задержки и, в некоторых случаях, не могли начать работу. Мы удалили классы ресурсов гена 3, одновременно решая проблемы стабильности, влияющие на них. К сожалению, рабочие процессы, которые мы не смогли обеспечить вычислительной мощностью в течение этого периода, были отменены. Пострадавшие клиенты должны изменить свой класс ресурсов с гена 3 на ген 2 и повторить эти рабочие процессы. Мы благодарим вас за терпение, пока наша команда работала над решением этой проблемы.

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

1. 22 июля 2026 г. в 06:13 UTCmonitoring

   Подмножество клиентов, возможно, испытали ошибки загрузки app.circleci.com начиная с 03:18 UTC. Было проведено исправление, и мы следим за полным восстановлением. Спасибо за ваше терпение, пока наши инженеры подтверждают выздоровление. В ближайшее время мы предоставим еще одно обновление.

2. 22 июля 2026 г. в 06:27 UTCresolved

   Между 03:18 UTC и 06:04 UTC 22 июля 2026 года подмножество клиентов не смогли получить доступ к app.circleci.com. Проблема решена, и доступ вернулся к норме. Мы благодарим вас за терпение, пока наша команда работала над внедрением исправления.

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

1. 20 июля 2026 г. в 00:35 UTCidentified

   Мы выявили проблему с запросами API GitHub, которая может привести к тому, что некоторые клиенты увидят, что рабочие процессы застряли в запущенном состоянии или рабочие процессы не начинаются. GitHub сообщил об инцидентах на API https://www.githubstatus.com/incidents/ph5nns5y4gxj https://www.githubstatus.com/incidents/8vfyvq16hzh9 Мы отслеживаем стабильность API GitHub и будем обновлять эту страницу по мере поступления дополнительной информации.

2. 20 июля 2026 г. в 01:24 UTCidentified

   Мы также видим ошибки обработки push event webhooks из-за отключения API. Пользователям, возможно, придется повторно использовать трубопроводы для этих push-событий.

3. 20 июля 2026 г. в 01:36 UTCmonitoring

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

4. 20 июля 2026 г. в 01:45 UTCresolved

   Частота ошибок GitHub API восстановилась до нормального уровня. Во время инцидента некоторые клиенты могли видеть, что трубопроводы не запускаются или не получают обновления статуса. Некоторые трубопроводы могут застрять в запущенном состоянии. Вы должны повторно нажимать фиксации или использовать пользовательский интерфейс для ручного запуска трубопроводов, которые не запускались. Трубопроводы в застрявшем состоянии должны быть отменены и повторно запущены. Если вы столкнулись с какими-либо проблемами, пожалуйста, обратитесь в службу поддержки CircleCI.

5. 23 июля 2026 г. в 21:10 UTCpostmortem

   ##Резюме 20 июля 2026 года с 00:22 до 01:45 UTC клиенты CircleCI, использующие интеграцию GitHub, испытали сбои в работе трубопроводов и застряли в рабочих процессах. Во время этого инцидента некоторые трубопроводы, запущенные пользователями, использующими GitHub, не запускались или запускались как трубопроводы ошибок. Клиенты, чьи трубопроводы вышли из строя или работали как трубопроводы ошибок во время этого окна, должны повторно запустить их. Это было вызвано деградацией API на GitHub (https://www.githubstatus.com/incidents/ph5nns5y4gxj), которая повлияла на многие API GitHub, которые CircleCI использует для запуска и запуска трубопроводов. К 01:45 UTC API GitHub восстановились, и трубопроводы клиентов работали нормально. Первоначальную страницу состояния CircleCI можно найти здесь (https://status.circleci.com/incidents/9lvbbbs9l87b). ##Что случилось (Все времена UTC) Начиная с 00:22 20 июля 2026 года, GitHub начал возвращать повышенные ошибки для следующих запросов API: * "приложения/*/токен" * "ответы/*/обязательства" * "repos/*/*/contents/*" * "repos/*/*/hooks" * "repos/*/*/hooks/*" * "repos/*/*/keys" * "repos/*/*/pulls" * "repos/*/*/statuses/*" CircleCI полагается на эти запросы для правильного запуска и запуска трубопроводов. В 00:22 наш внутренний мониторинг предупредил нас о проблеме. Наша команда начала расследование и обнаружила, что небольшое количество трубопроводов, принадлежащих проектам GitHub, либо не смогли запуститься, либо работали как трубопроводы ошибок. Это включало запланированные трубопроводы и рабочие процессы. Кроме того, небольшое количество рабочих процессов клиентов испытывало застрявшие рабочие места и требовало повторного запуска рабочего процесса для исправления. В 01:45 GitHub восстановился и обработка трубопроводов вернулась к нормальному рабочему уровню. Были затронуты только трубопроводы, запущенные во время инцидента, и клиенты должны повторно запустить эти трубопроводы. ##Профилактика и совершенствование процессов Мы активно работаем над повышением устойчивости обработки трубопроводов во время сбоев в обслуживании GitHub, чтобы уменьшить влияние подобных инцидентов на клиентов в будущем. Мы изучаем функции, которые помогут клиентам восстановиться с помощью уменьшенных ручных шагов после устранения инцидентов. Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

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

1. 16 июля 2026 г. в 23:04 UTCinvestigating

   Мы расследуем проблему, когда клиенты могут увидеть ошибки при загрузке веб-приложения CircleCI и входе в систему, а также неспособность начать или опоздать запланированные рабочие процессы. Это связано с продолжающимся инцидентом, затрагивающим GitHub. Вы можете следить за статусом GitHub по адресу https://www.githubstatus.com/incidents/gxycch3076xk. Наши инженеры ведут активные исследования. Мы предоставим еще одно обновление, как только у нас будет больше информации для обмена.

2. 16 июля 2026 г. в 23:42 UTCidentified

   Мы по-прежнему видим высокие показатели отказов от API GitHub, которые влияют на логин и обработку рабочих процессов. Мы продолжим мониторинг API GitHub для восстановления.

3. 17 июля 2026 г. в 00:09 UTCmonitoring

   Что происходит Инцидент, затрагивающий GitHub, был смягчен и в настоящее время контролируется на стороне GitHub. Вы можете следить за статусом GitHub по адресу https://www.githubstatus.com/. Чего можно ожидать Доступ к веб-приложению CircleCI, вход в систему, обработка конвейеров и рабочих процессов возвращаются к норме. Вы все еще можете видеть периодические ошибки или задержки запланированных трубопроводов и рабочих процессов по мере стабилизации систем. Спасибо за ваше терпение, пока мы следим за полным восстановлением.

4. 17 июля 2026 г. в 00:26 UTCresolved

   Инцидент, затрагивающий API GitHub, заставил клиентов CircleCI испытывать ошибки при загрузке веб-приложения и входе в систему, а также трубопроводы и запланированные рабочие процессы, которые не могут начаться или работать поздно. GitHub устранил основной инцидент (https://www.githubstatus.com/), и все затронутые функциональные возможности вернулись в нормальное русло. Клиенты, чьи рабочие места или трубопроводы потерпели неудачу, могут возобновить их. Планируемые трубопроводы и рабочие процессы, которые были пропущены во время инцидента, не будут работать автоматически. Мы благодарим вас за терпение.

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

1. 14 июля 2026 г. в 22:54 UTCidentified

   13 июля между 15:30 UTC и 22:40 UTC мы столкнулись с задержками с началом работы на классах ресурсов Docker (Gen 2) из-за ограничений пропускной способности нашего облачного провайдера. Задержки достигали примерно 1 минуты 48 секунд. Мы продолжаем испытывать эти задержки снова примерно с 15:45 UTC. До сих пор задержки достигали примерно 1 минуты 19 секунд. Мы работаем с нашим облачным провайдером, чтобы добавить емкость и обновить этот инцидент по мере изменения ситуации.

2. 15 июля 2026 г. в 00:32 UTCresolved

   13 июля между 15:30 UTC и 22:40 UTC мы столкнулись с задержками с началом работы на классах ресурсов Docker (Gen 2) из-за ограничений пропускной способности нашего облачного провайдера. Этот же вопрос повторился 14 июля между 15:45 UTC и 22:50 UTC. Задержки достигли 25 минут 13 июля и до 24 минут 14 июля. Средний + и 2 класса ресурсов X-large + показали самые длительные ожидания. Ранее в этом инциденте сообщалось о цифрах, основанных на среднем времени ожидания, что не отражало максимального воздействия, которое могли испытывать некоторые клиенты. Время ожидания теперь пришло в норму. Мы продолжаем работать с нашим облачным провайдером, чтобы добавить мощности в преддверии следующего пикового периода. Спасибо за ваше терпение.

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

1. 14 июля 2026 г. в 02:49 UTCinvestigating

   We are currently investigating login errors affecting some customers using Bitbucket as their identity provider.

2. 14 июля 2026 г. в 03:29 UTCinvestigating

   Our team continues to investigate login errors affecting some customers using Bitbucket as their identity provider.

3. 14 июля 2026 г. в 03:51 UTCinvestigating

   What's impacted Some customers logging in with a Bitbucket-linked identity are affected. This may also include customers logging in with GitHub but have a linked Bitbucket identity on their account. Additionally, some customers are experiencing workflows that are not starting or updating. What can you expect Affected customers may see login errors. Some customers may also notice workflows that fail to start or do not update as expected. Thank you for your patience while our engineers investigate. Next update We will provide another update as soon as we have more information to share

4. 14 июля 2026 г. в 04:21 UTCmonitoring

   What's impacted Some customers logging in with a Bitbucket-linked identity were affected. This may also have included customers logging in with GitHub who have a linked Bitbucket identity on their account. Some customers also experienced workflows that were not starting or updating. What can you expect A fix has been deployed. We are monitoring the situation to confirm full recovery. Next update We will provide an update if anything changes

5. 14 июля 2026 г. в 05:15 UTCresolved

   The issue where customers logging in with a Bitbucket-linked identity experienced login errors, and some customers experienced workflows that failed to start or did not update, has been resolved. What you may still experience and need to do - If you use Bitbucket as your login method, please log out and reauthenticate the CircleCI Bitbucket integration on your account. - If any of your workflows are stuck or showing missing status checks, please rerun them to pick up the fix. - If you continue to experience issues after taking these steps, please reach out to CircleCI Support. We thank you for your patience while our team worked on implementing a fix.

6. 14 июля 2026 г. в 22:31 UTCpostmortem

   ## Summary From 01:33 UTC to 05:18 UTC on July 14, 2026, customers with a Bitbucket-linked identity were unable to log in to CircleCI, and some customers experienced workflows that failed to start or update, due to a change in how Bitbucket's OAuth service reports account permissions. At 05:07 UTC, we deployed a fix that corrected how our systems read the updated permissions field. Some customers needed to log out and re-authenticate their Bitbucket integration after we deployed the fix. Our systems continued processing the backlog of affected jobs until 08:39 UTC. We thank our customers for their patience as we resolved this incident. Please reach out to our support team with any questions or concerns. The status page for this incident can be found [here](https://status.circleci.com/incidents/gsyjwybg477g). ## Background CircleCI supports logging in with a GitHub account, a Bitbucket account, or an email and password. When a customer logs in with a Bitbucket-linked identity, or when CircleCI needs to refresh the customer's access on their behalf, we exchange an authorization token with Bitbucket's OAuth service. This exchange includes a list of the permissions, or "scopes," the customer has granted us, which Bitbucket and CircleCI use to confirm what CircleCI is authorized to do on the customer’s behalf. ## What Happened \(All times UTC\) On April 8, 2026, [Bitbucket announced a change to its OAuth service](https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3139): it would be renaming the field used to report a customer's granted permissions. Bitbucket ran a transition period during which both the old and new field names were available, then fully removed the old field name on May 4, 2026. Our systems had not been updated to recognize the new field name, so once Bitbucket fully phased out the old one, requests that depended on it began to fail. At 01:33 on July 14, 2026, our systems began failing to process permissions information returned for Bitbucket-linked accounts, because our systems still expected the old permissions structure. This caused login attempts for all Bitbucket-linked accounts to fail, including for customers who log in with GitHub but have a Bitbucket identity linked to their account. At 01:59, automated monitoring alerted our engineering team to a spike in errors on the affected systems. The team began investigating immediately, confirmed customer impact at 02:38, and alerted customers via our status page at 02:51. By 03:00, the team had isolated the failures to the renamed Bitbucket field. Beginning at 03:17, workflow status updates for Bitbucket pipelines belonging to customers with an expired access token began to be dropped. The Bitbucket permissions check is used broadly across our platform, and these permissions failures also affected some of our internal job-processing systems. This caused a subset of workflows to become stuck without a final status, and caused some pull requests to show missing or stuck status checks. At 04:21, the team deployed an initial fix that resolved the underlying issue, restoring the login flow and returning our internal permissions system to normal operation. Some affected customers needed to log out and log back in to pick up the fix. By 05:07, the team deployed two additional fixes so our systems would begin accepting Bitbucket's new permissions field format going forward. We resolved the incident at 05:18. Some customers did need to log out and re-authenticate their Bitbucket integration before their account fully recovered. Our systems continued processing a backlog of affected jobs, returning to normal levels by approximately 08:39. ## Future Prevention and Process Improvement We are taking the following steps to prevent a recurrence and improve our response time: **We are hardening our authorization code against upstream API changes.** This incident happened because our system did not gracefully handle a renamed field in a response from a third-party identity provider. We will be immediately updating our authorization code so that unexpected or missing fields from GitHub, Bitbucket, and GitLab are handled safely. **We are improving how we track upstream provider changes.** We currently already monitor changelogs from our identity providers for exactly this kind of breaking change, but we didn't add this particular provider change to our monitoring in time to catch it before it shipped. We are auditing and expanding this monitoring so provider announcements reach our team before they affect customers. **We are improving how we classify and communicate incidents in their earliest minutes.** This incident's initial classification did not immediately reflect its customer-facing severity. We are refining our incident tooling and guidance to help engineers identify and communicate customer impact more quickly. **We are improving the resilience of our workflow-processing pipeline.** A downstream failure in this incident caused some workflow status updates to be dropped rather than retried or clearly surfaced. We are reviewing this system's retry and error-handling behavior so similar downstream failures are more visible and easier to recover from. Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. Please reach out to our support team with any questions or concerns.

1. 13 июля 2026 г. в 21:52 UTCinvestigating

   Мы получили несколько сообщений о периодических сетевых проблемах между нашей инфраструктурой Mac и провайдером VCS. Мы расследуем и предоставим обновления.

2. 13 июля 2026 г. в 22:21 UTCinvestigating

   Мы все еще расследуем эти прерывистые сетевые проблемы. Мы обновимся в ближайшее время, мы ценим ваше терпение.

3. 13 июля 2026 г. в 23:13 UTCinvestigating

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

4. 13 июля 2026 г. в 23:35 UTCmonitoring

   Мы определили проблему. Некоторые клиенты могут столкнуться с работой, которая зависает или не продвигается во время шагов Github из-за периодических проблем с сетью. Наши инженеры ведут активный мониторинг. В то же время мы добились успеха, увеличив время no output timeout до 15-20 минут, чтобы дать больше времени для приколов Github. Это можно сделать, следуя этому руководству сообщества: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

5. 14 июля 2026 г. в 13:59 UTCidentified

   К сожалению, все еще есть некоторые клиенты, которые могут столкнуться с работой, которая зависает или не продвигается во время шагов Github из-за постоянных проблем с сетью с нашим поставщиком инфраструктуры Mac. Наши инженеры активно работают над этим. Мы ценим ваше терпение. В то же время мы добились успеха, увеличив время no output timeout до 15-20 минут, чтобы дать больше времени для приколов Github. Это можно сделать, следуя этому руководству сообщества: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

6. 14 июля 2026 г. в 15:35 UTCidentified

   Наш поставщик инфраструктуры Mac тестирует изменения в конфигурации сети, чтобы изолировать источник проблемы. Мы активно проверяем, устраняет ли это влияние, и вскоре последует еще одно обновление. В то же время, увеличение времени no output timeout до 15-20 мин продолжает помогать: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

7. 14 июля 2026 г. в 16:31 UTCidentified

   Мы определили проблему как некоторые входящие маршруты от затронутого провайдера VCS, что приводит к значительному снижению доступной пропускной способности, что негативно влияет на время приема репо. Мы работаем с нашим поставщиком инфраструктуры Mac, чтобы попытаться перевести входящий трафик на другой маршрут, однако этот процесс может занять длительный период времени. Мы будем продолжать предоставлять обновления по мере их появления. Как мы уже сообщали в предыдущих обновлениях, увеличение времени no output timeout до 15-20 мин продолжает помогать: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

8. 14 июля 2026 г. в 16:58 UTCmonitoring

   Наш поставщик инфраструктуры Mac изменил входящие маршруты, и мы наблюдаем восстановление во время приема VCS. Мы будем продолжать следить за этим вопросом в течение следующих нескольких часов. Скоро мы обновимся.

9. 14 июля 2026 г. в 18:28 UTCmonitoring

   Мы продолжаем наблюдать медленное, прогрессивное восстановление во времена VCS. В ближайшее время мы продолжим мониторинг и обновление. Мы ценим ваше терпение.

10. 14 июля 2026 г. в 20:18 UTCinvestigating

    Мы начинаем видеть, как VCS снова поднимается. Наша инженерная команда активно исследует и работает с нашим поставщиком инфраструктуры Mac, чтобы решить эту проблему. Опять же, мы ценим ваше терпение.

11. 14 июля 2026 г. в 22:15 UTCmonitoring

    Наш поставщик инфраструктуры для Mac перенаправил больше трафика на работающих сетевых провайдеров, и мы снова видим значительное восстановление в VCS. Как всегда, наша инженерная команда будет продолжать внимательно следить за этим, и в ближайшее время мы предоставим еще одно обновление.

12. 14 июля 2026 г. в 23:18 UTCresolved

    Мы продолжаем наблюдать значительное восстановление времени VCS за последние пару часов. Мы собираемся урегулировать этот инцидент, и наша инженерная команда будет продолжать внимательно следить. Мы очень ценим ваше терпение, поскольку мы работали с нашим поставщиком инфраструктуры Mac. Пожалуйста, обратитесь в нашу службу поддержки, если у вас есть какие-либо проблемы.

13. 16 июля 2026 г. в 01:56 UTCpostmortem

    ## Summary From 18:00 UTC on July 13, 2026 to 23:18 UTC on July 14, 2026, some customers running jobs on CircleCI's macOS fleet experienced jobs that hung or failed to progress during GitHub fetch steps. For these customers, GitHub fetch steps which would ordinarily take 1-2 minutes took 20-30 minutes, and timed out. The issue was caused by a capacity and routing problem on the network path between our Mac infrastructure provider and GitHub, and the associated intermittent networking issues slowed down fetches from GitHub. During the entire incident, our team worked directly with our Mac infrastructure provider to identify and reroute traffic away from the affected network paths. We resolved an initial occurrence at 19:40 UTC on July 13. The issue recurred at 21:52 UTC that same day, we reopened the incident, and it was fully resolved by 23:18 UTC on July 14. Our macOS fleet had a similar issue several weeks ago. From 20:18 UTC on June 24, 2026 to 03:09 UTC on June 25, 2026, customers experienced a [similar incident](https://status.circleci.com/incidents/gvysjmkf4ct9) affecting the ability of macOS jobs to reach GitHub. That incident was also caused by a network routing problem in our Mac infrastructure provider. We thank our customers for their patience while we worked through this incident. Please see below for specific actions which CircleCI and our Mac infrastructure provider will be taking. Please reach out to our support team with any questions or concerns. The status pages for this incident can be found [here](https://status.circleci.com/incidents/n1tc2lw9q7l0) and [here](https://status.circleci.com/incidents/7cnl777wp9qz). ## Background CircleCI's macOS jobs are hosted on a third-party Mac infrastructure provider. That provider connects to the broader internet, including services like GitHub, over multiple redundant upstream network paths. When one of those paths is experiencing reduced capacity or a routing problem, jobs that are fetching code or dependencies from a destination along that network path can slow down or hang intermittently, even when CircleCI's own platform, the third-party infrastructure provider, and the destination service are all operating normally. ## What Happened _\(All times UTC\)_ At 18:00 on July 13, some customers running macOS jobs began experiencing intermittent failures and delays fetching code and dependencies from GitHub. We opened an investigation and alerted our customers via our status page at 18:55. By 19:04, our Mac infrastructure provider identified increased latency on one of its network paths and rerouted traffic around it. Fetch times recovered, and we moved the incident to `Monitoring` at 19:29, and to `Resolved` at 19:40. At 20:44 UTC, customers reported that the issue had returned. We reopened the incident and updated our status page to `Investigating` at 21:52. Over the following two hours, we worked closely with our infrastructure provider to gather diagnostic data in an effort to isolate the affected network path. In the meantime, we published guidance recommending that customers increase their `no_output_timeout` setting to 15–20 minutes, to allow more time for GitHub fetches to complete during the intermittent slowdowns, and moved the status page to `Monitoring` at 23:35. After publishing the workaround guidance at 23:35 UTC on July 13, we expected the underlying network issue to improve overnight. It did not. At 13:59 UTC on July 14, we confirmed that customers were still experiencing intermittent failures and moved the status page back to `Investigating`. Our engineering team reproduced the failure directly using our own testing tools, which helped confirm this was a general `git-fetch` issue rather than something specific to any particular build tool, container image, or software update. At 15:35, we updated the status page to share that our infrastructure provider was testing changes to its network configuration to isolate the source of the issue. At 16:31, we updated the status page again to share that we'd identified the cause as reduced inbound bandwidth on a specific route, and that we were working with our provider to shift traffic to a different route. At 16:36, our infrastructure provider identified the affected network paths and shifted traffic away from them, fetch times recovered, and at 16:58, we updated the status page to `Monitoring`. By early afternoon, some customers were again seeing slow fetch times, and we moved the status page back to `Investigating` at 20:18. Our infrastructure provider identified two additional network paths with degraded performance and shifted traffic away from them by 22:07. Fetch times stabilized over the following hour, and we marked the incident `Resolved` at 23:18. In total, customers running Mac jobs may have experienced intermittent job slowdowns or failures for portions of the window between 18:00 UTC on July 13 and 23:18 UTC on July 14. Our infrastructure provider has since reported clean test results across its network and believes the underlying capacity issue originated further upstream, closer to GitHub, rather than within its own network. We are continuing to monitor this closely. ## Future Prevention and Process Improvement We are taking the following steps to prevent a recurrence and improve our response time: **We are building additional automated monitoring for macOS fleet GitHub-fetch performance.** Our extensive automated monitoring did not catch this incident. We are now adding end-to-end monitoring for GitHub fetches in particular, in order to detect similar issues proactively. **We are working directly with our Mac infrastructure provider on faster, more proactive detection.** We are asking our provider to build monitoring that can detect a degraded network path and reroute around it automatically, rather than relying on CircleCI to identify and request a reroute during an active incident. **We are turning the diagnostic tooling we built during this incident into a standing capability.** This will let us detect and reproduce this class of network failure on demand going forward, rather than assembling test infrastructure during an active incident. **We are reviewing our incident response process for a sufficient confirmation window before marking a network-related incident Resolved.** This incident briefly recurred after an early, premature resolution; we are formalizing a minimum period of confirmed-clean monitoring before closing incidents of this type. We will continue to provide regular updates along the way as investigation and remediation continues. **We are actively moving from a single provider for Mac infrastructure** **to multiple providers.** This will allow CircleCI to route incoming customer workloads to the most available and best-performing provider. Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. Please reach out to our support team with any questions or concerns.

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

1. 13 июля 2026 г. в 18:55 UTCinvestigating

   Мы получили сообщения о периодических сетевых проблемах между нашей инфраструктурой Mac и провайдером VCS. Мы расследуем и предоставим обновления.

2. 13 июля 2026 г. в 19:11 UTCidentified

   Мы работаем с нашим поставщиком инфраструктуры Mac, чтобы попытаться смягчить ситуацию. Скоро снова обновится.

3. 13 июля 2026 г. в 19:29 UTCmonitoring

   Наш поставщик инфраструктуры Mac внедрил исправление, мы начинаем видеть восстановление. Мы проверяем и скоро обновимся.

4. 13 июля 2026 г. в 19:40 UTCresolved

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

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