6 августа в 15:22 UTC новый сбой GitHub ударил по двум сервисам, без которых у многих команд не двигается ни деплой, ни документация: Actions сначала ушел в деградацию, а затем начал срывать запуски workflow, а Pages попал в список затронутых систем чуть позже. Для разработчиков, продактов и IT-руководителей это уже не неприятный эпизод, а сигнал, что зависимость от одного SaaS в CI/CD и хостинге превращается в операционный риск.
Как пишет The Register, примерно через 20 минут после первого сообщения GitHub признал, что страдает не только производительность, но и доступность Actions. Дальше картина стала еще мрачнее: workflow либо не стартуют, либо падают на середине выполнения, запросы к Actions REST API возвращают ошибки, а пользователи внезапно упираются в rate limits, которых в штатном режиме не ждали. Почти сразу стало ясно, что одним CI дело не ограничилось: в список пострадавших добавили Pages, а к 17:40 UTC GitHub сообщил, что инцидент задел еще и Copilot code review, Copilot coding agent, hosted runners, миграции через GitHub Enterprise Importer и доставку webhook. Причину сервис, по его словам, уже обнаружил, но на момент последнего обновления проблема оставалась нерешенной.
Если бы это был единичный сбой GitHub, новость закончилась бы на статус-странице. Но у GitHub сейчас другая проблема: инциденты идут слишком плотной серией. Аналогичный сбой Actions случился 29 июля. За июль компания зафиксировала 26 инцидентов, за июнь — 23, за май — еще 23, за апрель — 26. Август только начался, а в истории статусов уже шесть записей за первые шесть дней месяца. Для платформы, которая давно стала стандартом де-факто для размещения кода, сборок, документации и автоматизации релизов, это статистика не из категории «бывает», а из категории «пора пересматривать допущения».
GitHub уже извинялся за затяжную полосу сбоев в апреле и в июне обещал заняться не косметическим ремонтом, а архитектурными изменениями. Тогда старший вице-президент GitHub Якуб Олексы говорил о структурных улучшениях, которые должны убрать сами сценарии отказов, а не просто тушить последствия каждого нового инцидента. По истории статусов пока выходит обратное: либо эти меры еще не доехали до продакшена, либо их эффект заметно слабее заявленного. На бумаге GitHub движется к более надежной платформе, на практике пользователи видят все ту же ленту статусов с почти серийным номером у каждого сбоя.
Отдельно неудобно то, что GitHub раньше сам связывал часть проблем с ростом AI-нагрузки на инфраструктуру. Ирония тут почти в лоб: нынешний инцидент задел не только базовый CI/CD, но и Copilot code review с coding agent, то есть те самые AI-функции, которыми компания активно продает следующее поколение разработки. На этом фоне публичное раздражение уже выплескивается наружу. Разработчик Ghostty Митчелл Хасимото заявил, что GitHub стал настолько нестабильным, что перестает быть местом для серьезной работы. Когда так говорит не случайный комментатор, а автор заметного open source-проекта, это звучит как предупреждение для всей экосистемы.
Самый неприятный тип аварии здесь даже не полный даунтайм, а вязкая деградация, когда часть процессов будто бы жива, но доверять им уже нельзя. Если workflow у одних команд не стартуют, у других падают на середине, а API параллельно отдает ошибки и странные лимиты, инженеры сначала ищут баг у себя, теряют часы на ложную диагностику, и только потом понимают, что проблема у платформы. С Pages история такая же: когда хостинг не лежит окончательно, а работает нестабильно, ломаются документация, превью-сборки, внутренние порталы и публичные статические сайты, которые многие считали самым беспроблемным кусочком GitHub.
Для бизнеса это уже не вопрос репутации бренда, а вполне прикладная математика риска. Если релизы завязаны на GitHub Actions, документация и лендинги размещены в Pages, миграции идут через экосистему GitHub, а часть интеграций живет на webhook, один инцидент мгновенно расползается по нескольким слоям процессов. Сначала встают проверки и сборки, затем сдвигается деплой, следом начинают хромать боты, уведомления и внутренняя автоматика. У крупных компаний обычно есть обходные маршруты, свои раннеры и запас по времени. У стартапов и небольших продуктовых команд запас чаще один: ночь, в которую релиз так и не доехал до пользователей.
На этом фоне главный вопрос для рынка звучит уже не так: «бывают ли у GitHub сбои». Он звучит иначе: сколько критичных функций отрасль готова держать на одной платформе без запасного сценария. Пока GitHub одновременно наращивает AI-нагрузку и продолжает собирать двузначное число инцидентов месяц за месяцем, его главным конкурентным преимуществом становится не очередная умная функция, а скучная надежность, которой разработчики ждут заметно сильнее любых агентных новинок.