Утром 8 июня пользователи GitHub начали сообщать о сбоях и нестабильной работе сервиса. Проблема быстро стала заметной на мониторинговых площадках: часть пользователей жаловалась на недоступность сайта, ошибки входа и нестабильную работу отдельных функций. Позже сбой подтвердился и в официальном статусе GitHub: компания открыла инцидент под названием “Сбои в работе некоторых сервисов GitHub”. В первом сообщении GitHub заявил: “Мы изучаем сообщения о снижении производительности некоторых сервисов GitHub”, а через несколько минут уточнил, что GitHub Issues работает с пониженной доступностью: “Проблемы возникают из-за снижения доступности. Мы продолжаем расследование.”
На первый взгляд сбой GitHub Issues может показаться не таким критичным, как полное падение репозиториев или GitHub Actions. Но для разработчиков Issues — это не просто раздел с комментариями. Там ведут баг-репорты, задачи, обсуждения релизов, внутренние планы, дорожные карты и коммуникацию между командами. Если этот инструмент работает нестабильно, разработка может не остановиться полностью, но процесс быстро теряет прозрачность: сложно понять, какие ошибки уже исправлены, какие задачи приоритетные и кто за что отвечает.
Читайте также
Coinbase восстановила торговлю на рынках прогнозов после сбоя
Параллельно сторонние сервисы мониторинга также фиксировали признаки проблем. StatusGator сообщил о возможном сбое GitHub и указал на жалобы пользователей, включая ошибки сервера, медленную работу, проблемы с подключением и недоступность сервиса. На момент проверки сервис также упоминал сообщения о сбоях. Действия GitHub из-за ошибок шлюза и более 100 пользовательских репортов за последние сутки. Downdetector также показывал “возможные проблемы с GitHub”, (152 за час) а среди наиболее частых жалоб выделялись проблемы с сайтом, входом и приложением.
Почему это важно? GitHub давно стал не просто хранилищем кода, а инфраструктурой для всей современной разработки. Через него компании ведут проекты, принимают pull request, запускают CI/CD, публикуют open-source-библиотеки и управляют задачами. Поэтому даже частичный сбой может затронуть не только программистов, но и бизнес-процессы: релизы откладываются, автоматические проверки зависают, команды теряют общий контекст.
При этом нынешний инцидент происходит на фоне уже заметного внимания к надежности GitHub. В майском отчете о доступности компания признала, что в апреле зафиксировала 10 инцидентов, которые привели к ухудшению работы различных сервисов GitHub. В том же отчете GitHub отдельно описывал, например, сбой поиска кода 1 апреля, когда 100% поисковых запросов временно не выполнялись. Это не означает, что сегодняшняя проблема связана с теми же причинами, но показывает: нагрузка на платформу растет, а стабильность таких сервисов становится вопросом не удобства, а производственной устойчивости.
Пока GitHub не назвал точную причину текущего сбоя. Поэтому преждевременно говорить о кибератаке, потере данных или масштабной аварии. На данный момент официально подтверждено только расследование проблем с производительностью и пониженная доступность GitHub Issues. Пользователям и компаниям стоит следить за страницей GitHub Status, временно фиксировать важные задачи в резервных системах и не планировать критические релизы без проверки доступности нужных инструментов. Сбой GitHub снова напоминает: даже крупнейшие облачные платформы не защищены от технических проблем. Для разработчиков это повод держать локальные копии репозиториев, резервные каналы коммуникации и минимальный план действий на случай недоступности ключевых сервисов.
Меню 
Знания 
События 
Новости 
Курсы валют