На пике примерно 20% запросов к веб-интерфейсу и API завершались ошибкой. Для загрузки архивов и «сырых» файлов репозиториев этот показатель достигал около 50%. Это не означает, что ровно 20% пользователей полностью потеряли доступ: речь идет о доле ошибочных запросов в соответствующих категориях.

Главная оговорка: публичные сообщения пока не раскрывают первопричину сбоя. GitHub сообщил, что обнаружил проблемный компонент и применил исправление, но пообещал опубликовать подробный анализ позже.

Хронология: от первых ошибок к поэтапному восстановлению

GitHub начал расследование примерно в 13:40 UTC, или в 16:40 по московскому времени, 17 августа. Сбой быстро распространился между сервисами, которые разработчики используют для доступа к коду, проверки изменений, запуска автоматических сборок и доставки программного обеспечения.

К обновлению, опубликованному в 12:36 по времени Восточного побережья США — 16:36 UTC, — компания сообщила, что обнаружила проблемный компонент и предприняла корректирующие действия. Платформа демонстрировала явные признаки восстановления, но еще не вернулась к полной стабильности.

Восстановление проходило не одновременно для всех функций. Основные сервисы постепенно возвращались в рабочее состояние, тогда как у Copilot сохранялись проблемы с аутентификацией в отдельных приложениях. По данным мониторинга инцидента, общая продолжительность сбоя составила примерно семь с половиной часов — до около 21:15 UTC.

Какие сервисы пострадали

Наиболее заметные последствия выглядели так:

• Веб-интерфейс и API: около 20% ошибок.
• Архивы и исходное содержимое репозиториев: около 50% ошибочных загрузок.
• Инструменты разработки: Pull Requests, Issues, Actions, Webhooks, Git Operations и Pages в разные моменты работали с перебоями или были недоступны.
• GitHub Copilot: сервис AI-помощи при программировании оставался проблемным даже после восстановления ряда основных функций.
• Корпоративная идентификация: сообщения об инциденте указывали на нарушения в SAML- и OIDC-аутентификации, SCIM-подготовке учетных записей и Team Sync. Для организаций это могло означать проблемы со входом сотрудников и управлением доступом.

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

Сколько было сообщений о сбое

Показания сервисов мониторинга различались в зависимости от времени и методики подсчета. Один из отчетов сообщал о более чем 10 000 обращений к Downdetector к 8:12 утра по тихоокеанскому времени, тогда как в другом обновлении упоминался пик примерно в 3 000 сообщений.

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

Почему понедельник усилил эффект

Сбой пришелся на утро понедельника в США — начало рабочей недели для многих инженерных команд. В этот момент обычно запускаются первые проверки кода, сборки и тесты, открываются запросы на слияние, планируются релизы и обновления инфраструктуры.

Поскольку одновременно были затронуты Actions, Pull Requests, API и Webhooks, команды могли столкнуться не с одной изолированной неисправностью, а с цепочкой проблем: код не скачивался, проверка изменений не запускалась, автоматическая сборка зависала, а уведомление о результате не доходило.

Что сделал GitHub и чего пока не объяснил

Из публичных обновлений компании можно уверенно установить три факта:

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

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

Часть более широкой проблемы надежности

Августовский сбой произошел после непростого периода для GitHub. В отчете о доступности за июль компания описала восемь инцидентов. Один из них, 8 июля, продолжался более семи часов и затронул веб-интерфейс, REST API, GraphQL API, Actions, Packages, Copilot и Git Operations в некоторых средах Enterprise Cloud.

В мае GitHub объяснял растущую нагрузку распространением AI-помощников и агентных сценариев разработки — когда программные агенты самостоятельно создают изменения, открывают запросы и запускают автоматизацию. Компания заявила, что переносит часть мощностей в Azure, разделяет сервисы и старается убрать общие точки отказа.

Масштаб планов также изменился. Изначально GitHub рассчитывал увеличить емкость в 10 раз, но к февралю 2026 года пришел к выводу, что проектировать инфраструктуру нужно уже с расчетом на 30-кратный рост относительно прежнего масштаба. Отдельные публикации также сообщали о планах задействовать дополнительные мультиоблачные мощности, включая AWS, однако сами по себе эти планы не объясняют причины августовского сбоя.

Проблема для клиентов заключается в концентрации зависимостей. GitHub сегодня — это не только хостинг Git-репозиториев, но и система совместной работы, автоматизации, развертывания, корпоративной идентификации и AI-помощи. Если сбоит общий компонент, одновременно могут остановиться доступ к коду, ревью, сборки, релизы, вебхуки и Copilot.

Что стоит учесть компаниям

Августовский инцидент не доказывает, что разработчики массово откажутся от GitHub, и не дает оснований прогнозировать скорую миграцию на другие платформы. Но он показывает, насколько рискованной может быть зависимость производственного процесса от одного сервиса.

Организациям имеет смысл заранее проверить несколько мер:

• хранить резервные копии репозиториев или поддерживать зеркала;
• делать конфигурации CI/CD переносимыми;
• документировать аварийный выпуск релиза без GitHub Actions и hosted runners;
• продумать запасной способ работы при недоступности SSO, Webhooks или корпоративного управления доступом;
• регулярно проверять, можно ли восстановить сборку и доставку продукта вне основной платформы.

Эти меры не устраняют риск сбоя, но уменьшают его последствия. Окончательная оценка инцидента 17 августа будет зависеть от постмортема GitHub. Пока наиболее осторожный вывод таков: платформа пережила широкий каскадный сбой с особенно тяжелыми последствиями для загрузки репозиториев и связанных процессов разработки, восстановление шло поэтапно, а техническая первопричина еще не раскрыта.

На пике примерно 20% запросов к веб-интерфейсу и API завершались ошибкой. Для загрузки архивов и «сырых» файлов репозиториев этот показатель достигал около 50%. Это не означает, что ровно 20% пользователей полностью потеряли доступ: речь идет о доле ошибочных запросов в соответствующих категориях.

Главная оговорка: публичные сообщения пока не раскрывают первопричину сбоя. GitHub сообщил, что обнаружил проблемный компонент и применил исправление, но пообещал опубликовать подробный анализ позже.

Хронология: от первых ошибок к поэтапному восстановлению

GitHub начал расследование примерно в 13:40 UTC, или в 16:40 по московскому времени, 17 августа. Сбой быстро распространился между сервисами, которые разработчики используют для доступа к коду, проверки изменений, запуска автоматических сборок и доставки программного обеспечения.

К обновлению, опубликованному в 12:36 по времени Восточного побережья США — 16:36 UTC, — компания сообщила, что обнаружила проблемный компонент и предприняла корректирующие действия. Платформа демонстрировала явные признаки восстановления, но еще не вернулась к полной стабильности.

Восстановление проходило не одновременно для всех функций. Основные сервисы постепенно возвращались в рабочее состояние, тогда как у Copilot сохранялись проблемы с аутентификацией в отдельных приложениях. По данным мониторинга инцидента, общая продолжительность сбоя составила примерно семь с половиной часов — до около 21:15 UTC.

Какие сервисы пострадали

Наиболее заметные последствия выглядели так:

• Веб-интерфейс и API: около 20% ошибок.
• Архивы и исходное содержимое репозиториев: около 50% ошибочных загрузок.
• Инструменты разработки: Pull Requests, Issues, Actions, Webhooks, Git Operations и Pages в разные моменты работали с перебоями или были недоступны.
• GitHub Copilot: сервис AI-помощи при программировании оставался проблемным даже после восстановления ряда основных функций.
• Корпоративная идентификация: сообщения об инциденте указывали на нарушения в SAML- и OIDC-аутентификации, SCIM-подготовке учетных записей и Team Sync. Для организаций это могло означать проблемы со входом сотрудников и управлением доступом.

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

Сколько было сообщений о сбое

Показания сервисов мониторинга различались в зависимости от времени и методики подсчета. Один из отчетов сообщал о более чем 10 000 обращений к Downdetector к 8:12 утра по тихоокеанскому времени, тогда как в другом обновлении упоминался пик примерно в 3 000 сообщений.

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

Почему понедельник усилил эффект

Сбой пришелся на утро понедельника в США — начало рабочей недели для многих инженерных команд. В этот момент обычно запускаются первые проверки кода, сборки и тесты, открываются запросы на слияние, планируются релизы и обновления инфраструктуры.

Поскольку одновременно были затронуты Actions, Pull Requests, API и Webhooks, команды могли столкнуться не с одной изолированной неисправностью, а с цепочкой проблем: код не скачивался, проверка изменений не запускалась, автоматическая сборка зависала, а уведомление о результате не доходило.

Что сделал GitHub и чего пока не объяснил

Из публичных обновлений компании можно уверенно установить три факта:

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

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

Часть более широкой проблемы надежности

Августовский сбой произошел после непростого периода для GitHub. В отчете о доступности за июль компания описала восемь инцидентов. Один из них, 8 июля, продолжался более семи часов и затронул веб-интерфейс, REST API, GraphQL API, Actions, Packages, Copilot и Git Operations в некоторых средах Enterprise Cloud.

В мае GitHub объяснял растущую нагрузку распространением AI-помощников и агентных сценариев разработки — когда программные агенты самостоятельно создают изменения, открывают запросы и запускают автоматизацию. Компания заявила, что переносит часть мощностей в Azure, разделяет сервисы и старается убрать общие точки отказа.

Масштаб планов также изменился. Изначально GitHub рассчитывал увеличить емкость в 10 раз, но к февралю 2026 года пришел к выводу, что проектировать инфраструктуру нужно уже с расчетом на 30-кратный рост относительно прежнего масштаба. Отдельные публикации также сообщали о планах задействовать дополнительные мультиоблачные мощности, включая AWS, однако сами по себе эти планы не объясняют причины августовского сбоя.

Проблема для клиентов заключается в концентрации зависимостей. GitHub сегодня — это не только хостинг Git-репозиториев, но и система совместной работы, автоматизации, развертывания, корпоративной идентификации и AI-помощи. Если сбоит общий компонент, одновременно могут остановиться доступ к коду, ревью, сборки, релизы, вебхуки и Copilot.

Что стоит учесть компаниям

Августовский инцидент не доказывает, что разработчики массово откажутся от GitHub, и не дает оснований прогнозировать скорую миграцию на другие платформы. Но он показывает, насколько рискованной может быть зависимость производственного процесса от одного сервиса.

Организациям имеет смысл заранее проверить несколько мер:

• хранить резервные копии репозиториев или поддерживать зеркала;
• делать конфигурации CI/CD переносимыми;
• документировать аварийный выпуск релиза без GitHub Actions и hosted runners;
• продумать запасной способ работы при недоступности SSO, Webhooks или корпоративного управления доступом;
• регулярно проверять, можно ли восстановить сборку и доставку продукта вне основной платформы.

Эти меры не устраняют риск сбоя, но уменьшают его последствия. Окончательная оценка инцидента 17 августа будет зависеть от постмортема GitHub. Пока наиболее осторожный вывод таков: платформа пережила широкий каскадный сбой с особенно тяжелыми последствиями для загрузки репозиториев и связанных процессов разработки, восстановление шло поэтапно, а техническая первопричина еще не раскрыта.