GitHub борется с масштабным сбоем в Actions, Issues и Pull Requests
Incident with Actions, Pull Requests and Issues
12 октября 2026 года GitHub сообщил о деградации производительности сразу в нескольких ключевых сервисах: Actions, Issues и Pull Requests. Пользователи столкнулись с проблемами загрузки вкладки Actions, взаимодействия с Checks API, постановки новых запусков в очередь, создания и обновления issues, а также запросов на ревью через REST и GraphQL API. Первоначальные меры по смягчению последствий не принесли полного успеха, и сбой затронул даже уведомления.
Наша первоначальная мера по смягчению последствий не увенчалась полным успехом, и пользователи по-прежнему могут сталкиваться с задержками и ошибками в Actions, issues и projects, а уведомления задерживаются.
- bearjaws
Люди хотят обосрать GitHub, но, честно говоря, переход с 50 млн <чего-то> в день на 2 млрд <чего-то> в день сломает практически любую систему, которую здесь кто-либо когда-либо строил. Даже если это происходило за ~8 месяцев, многое начнёт падать, и пока ты латаешь одно, следующая костяшка домино валится.
Мне жаль команду, но для всех это будет отличной возможностью для роста.
- orsenthil
Ага, только вчера я дал claude собрать и задеплоить мне сквозной проект, который будет мигать моей лампочкой lifx, когда в любой опенсорсный проект прилетает коммит. Утром я увидел, что он остановился где-то в 23:00 по PST вчера. Я задавался вопросом, почему, и думал о том, как легко сделать полностью рабочий проект вроде этого за минуты и что мешает людям делать сотни таких проектов в день. GitHub не был построен для такого сценария.
- mglvsky
Почему они не написали что-то вроде «пожалуйста, сделай всю систему надёжнее, не делай ошибок»?
- kqgnkqgn
Учитывая, что у GitHub, похоже, постоянно возникают эти проблемы с масштабированием, по моему мнению, верно одно из двух:
1) либо они менее компетентны в управлении крупномасштабной инфраструктурой по сравнению с другими крупными технологическими компаниями
2) либо сам git добавляет уникальные сложности, которые затрудняют масштабирование
Я думаю, что 2) гораздо вероятнее, чем 1).
Так почему бы не отказаться от git? Возможно ли создать новую VCS, которая масштабируется лучше, если начать с нуля?
Очевидно, что добиться принятия чего-то другого было бы сложно. Но у GitHub достаточно доли рынка, чтобы они могли это провернуть. Особенно используя затраты или надёжность, чтобы стимулировать миграцию.
(Не говорю, что это обязательно будет хорошо для сообщества в целом, но думаю, что хорошо для GitHub.)
- throwitaway222
Возможно, им нужно сделать actions бесплатными и actions plus. Actions free делает всё, что делает текущий продукт, но имеет отложенные обновления в UI. И, возможно, actions free/plus вместо этого отправляют обновления в вашу собственную агентную инфраструктуру. Просто настройте URL, и все обновления ваших actions идут туда
- zanderwohl
Я не понимал и до сих пор не понимаю, почему все запирают себя в CI/CD-пайплайне GitHub. Настроить проверки, работающие на обычном docker-окружении, несложно. У меня есть домашний сервер, который я использую для всех своих сборок и проверок, с конфигом github actions для ручного запуска, если я не могу подключиться по VPN к своей домашней сети.
Помимо того, что это надёжнее, на машине, которую ты контролируешь, это просто быстрее.
- igsomething
Сколько времени пройдёт, прежде чем они поднимут цены на свои планы и сократят бесплатные минуты Actions, чтобы отпугнуть плохих пользователей? Я бы предпочёл 500 минут в месяц надёжного GHA, чем это.
- loveparade
Я думаю, было бы эффективнее постить на HN, когда выдаётся день без проблем с GitHub.