GitHub 17 августа столкнулся с масштабным сбоем, который затронул веб-интерфейс, API, Git-операции, Actions, Issues, Pull Requests, Pages, Webhooks и Copilot. В самый тяжёлый период платформа фиксировала около 20% ошибок для сайта и API, а при загрузке архивов и необработанного содержимого репозиториев показатель приближался к 50%.
Что произошло с GitHub 17 августа
Первые сообщения о проблемах появились на официальной странице состояния GitHub в 13:40 UTC, или в 16:40 по московскому времени. Сначала пользователи сталкивались с медленной загрузкой и ошибками в отдельных разделах, но затем перечень затронутых компонентов быстро расширился.
Проблемы возникали при работе с pull request, задачами, автоматическими сборками и вебхуками. Часть разработчиков не могла стабильно выполнять Git-операции, а корпоративные клиенты столкнулись со сбоями SAML- и OIDC-аутентификации, SCIM и синхронизации команд.
GitHub сообщил, что нашёл проблемный компонент и применил корректирующие меры. Основные сервисы начали восстанавливаться, однако некоторое время сохранялись отдельные ошибки авторизации. Хронология инцидента остаётся доступной на официальной странице GitHub Status.
Какие сервисы пострадали
- GitHub.com и API — ошибки при открытии страниц и выполнении запросов;
- Git Operations — нестабильные pull, push и другие операции с удалёнными репозиториями;
- GitHub Actions — задержки и ошибки в автоматических сценариях сборки и развёртывания;
- Issues и Pull Requests — проблемы с загрузкой задач, обсуждений и проверок кода;
- Pages и Webhooks — сбои публикации и доставки событий во внешние системы;
- Copilot — недоступность или нестабильная работа функций помощника.
Одновременный отказ нескольких компонентов особенно заметен в компаниях, где GitHub служит не только хранилищем кода, но и центром сборки, тестирования, ревью и выпуска продукта.
Почему локальный Git продолжает работать
Git — распределённая система контроля версий. Полная история проекта обычно хранится в локальном клоне, поэтому разработчик может создавать ветки, делать коммиты, просматривать изменения и объединять код даже при недоступности GitHub.
Ограничения начинаются там, где требуется удалённый сервис: отправка изменений коллегам, запуск облачных Actions, публикация релиза, проверка pull request или получение пакета из внешнего реестра.
Как подготовиться к следующему сбою
- Не хранить единственную копию только на платформе. У команды должен быть актуальный локальный клон и резервная копия критичных репозиториев.
- Зафиксировать зависимости. Lock-файлы и локальный кэш уменьшают риск остановки сборки из-за недоступного внешнего ресурса.
- Отделить выпуск от одного CI-сервиса. Для критичных проектов полезен документированный ручной сценарий сборки и развёртывания.
- Сохранить резервный канал связи. Обсуждение инцидента не должно зависеть от Issues или Discussions на той же платформе.
- Подписаться на статус. GitHub предлагает уведомления по электронной почте, SMS, Slack, RSS и вебхукам.
После восстановления сервиса перед повторным запуском сборки стоит проверить, не создались ли дубли релизов, задач или запросов на развёртывание. Автоматический повтор операции после тайм-аута иногда приводит к тому, что действие всё же было принято сервером, хотя интерфейс показал ошибку.
Надёжность рабочих инструментов особенно важна на фоне роста автоматизированного анализа кода. Ранее Digital Report разбирал, зачем модель GLM-5.3 учат искать уязвимости.
- ИИ OpenAI предложил решение задачи Навье—Стокса: почему миллион долларов пока никто не выиграл - 09.09.2026
- Nintendo Direct 9 сентября 2026: во сколько смотреть и какие игры покажут для Switch 2 - 09.09.2026
- «Лучшую игру в истории» пересобрали заново: Nintendo показала ремейк Zelda: Ocarina of Time для Switch 2 - 08.09.2026
