26 августа сбой GitHub Actions снова ударил по разработчикам, которые завязали сборки, тесты и деплой на экосистему GitHub. Инцидент длился почти три часа и случился всего через шесть дней после громких обещаний компании подтянуть надежность платформы, так что для команд с CI/CD на GitHub это уже не просто неприятность, а вполне прикладной риск для релизного календаря.
Как пишет The Register, проблемы начались в 15:11 UTC. По данным статуса GitHub, команда обнаружила неполадку на основной базе данных и переключилась на реплику, но это не сняло деградацию полностью. После этого GitHub ограничил входящий трафик, параллельно разбираясь с проблемами на уровне Vitess, а затем стал постепенно возвращать нагрузку. К 18:00 UTC компания заявила, что Actions работает штатно, а очереди входящих задач восстановлены. Для пользователей это означает привычную картину: workflow либо не стартуют вовремя, либо висят в очередях, либо отрабатывают с ошибками в самый неудобный момент.
Сам по себе один инцидент не выглядел бы сенсацией, если бы не фон. У GitHub в 2026 году явно не ладится с надежностью, и сбой GitHub Actions уже трудно списывать на неудачное совпадение. Архив статус-страницы показывает 25 инцидентов в январе, 37 в феврале, 32 в марте, 26 в апреле, 23 в мае, 23 в июне, 26 в июле и 23 в августе на момент публикации статьи, хотя до конца месяца оставалось еще несколько дней. Иными словами, в каждом месяце этого года платформа набирала как минимум 23 сбоя. Для сервиса, который многие команды используют как основу инженерного конвейера, это уже статистика не из разряда «бывает», а из разряда «надо планировать запасной вариант».
Особенно болезненно выглядит именно история с Actions. Это не периферийный сервис, а одна из центральных частей GitHub для современной разработки: автоматические тесты, сборка артефактов, выкладка в staging и production, проверка pull request, security-сканы, release automation. Когда проседает этот слой, у команды может быть живой репозиторий, доступный API и даже работающий интерфейс GitHub, но фактическая доставка кода встает. Для стартапа это задержка релиза, для продуктовой команды потеря темпа, для enterprise-IT еще и лишний вопрос от бизнеса: почему облачный инструмент, за который платят не только деньгами, но и зависимостью, опять не держит нагрузку.
Обещания пока не конвертируются в аптайм
Неловкость ситуации добавляет тайминг. Всего за шесть дней до нового инцидента, после крупного сбоя 17 августа, GitHub уже выходил с объяснениями и обещаниями исправиться. Тогда почти восемь часов деградировали сразу несколько сервисов: Issues, Pull Requests, API, Actions и Copilot, что заметно парализовало работу клиентов. CTO GitHub Владимир Федоров тогда признал, что компания подвела пользователей, и пообещал нарастить масштабирование платформы под растущую аудиторию. Формулировка была предельно понятной: доверие нужно заработать стабильностью и способностью системы выдерживать рост. Но уже 26 августа этот тезис пришлось проверять на практике, и проверку он не прошел.
GitHub при этом сам же подчеркивал, что нагрузка на платформу растет очень быстро. По словам компании, сейчас она обслуживает вдвое больше коммитов, чем в апреле. В публикации The Register также приводятся цифры масштаба: 2,9 млрд коммитов, 24 млн новых репозиториев и 130 млн слитых pull request в месяц. На бумаге это выглядит как демонстрация мощи платформы. На земле, где инженеру нужно просто дождаться зеленого пайплайна, те же цифры начинают звучать как объяснение, почему система регулярно спотыкается. Особенно если аптайм GitHub Actions за август, по данным страницы доступности, составил лишь 98,13%. До «трех девяток» тут дистанция огромная, а для инфраструктурного сервиса это уже неприятный уровень, который сложно не заметить даже командам без жестких SLO.
Отдельный штрих этой истории в том, на что GitHub списывает часть проблем. Компания уже не раз говорила, что всплеск использования связан не только с людьми, но и с ботами и агентами ИИ, которые резко увеличили нагрузку. С технической точки зрения объяснение правдоподобное: автоматизированные системы действительно умеют создавать очень плотный трафик, особенно когда речь идет о генерации кода, массовых проверках, роботизированных коммитах и бесконечных workflow. Но для клиента это слабое утешение. Если платформа активно продает автоматизацию, Copilot и все вокруг AI-assisted development, то аргумент «нас слишком активно используют» выглядит не как оправдание, а как описание собственного операционного долга.
Что это значит для команд
Для русскоязычной IT-аудитории здесь вывод довольно приземленный. Если критичные релизы, hotfix-процессы или клиентские SLA завязаны только на GitHub Actions, стоит проверить, насколько у команды вообще есть план на случай очередной деградации. Речь не обязательно о полном уходе на другой CI/CD-движок. Иногда достаточно заранее понять, какие пайплайны можно временно перенести, какие шаги допускают ручной запуск, какие окна релиза нельзя ставить впритык, а где нужен запас по времени и отдельный канал мониторинга статуса GitHub. Потому что сбой GitHub Actions в 2026 году уже перестал быть сюрпризом, а значит, внезапным он остается только для тех, кто не заложил его в процесс.
Главный вопрос теперь не в том, сможет ли GitHub пережить еще один напряженный месяц, а в том, когда рынок начнет воспринимать регулярные сбои не как временные трудности роста, а как новую норму крупнейшей платформы для разработки. И если август закончится с очередным заметным числом инцидентов, разговор о надежности GitHub придется вести уже не языком извинений и постмортемов, а языком архитектурных ограничений и доверия, которое уходит быстрее, чем восстанавливаются очереди задач.