GitHub знову cooked? Ось сайт, який показує історію його збоїв за 10 років

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Якщо вам якось здавалося, що GitHub останнім часом лежить підозріло часто, тепер для цього відчуття є окремий сайт)

Попався цікавий проєкт «Is GitHub Cooked?». Ресурс збирає історію інцидентів GitHub за останні десять років та показує їх у вигляді дашбордів. Дані беруться з офіційного GitHub Status, хоча сам сайт із платформою не пов’язаний.

Автор пояснює, що хотів фільтрувати історію інцидентів за сервісами та рівнями серйозності, які впливають на його продукти, тож зробив цей ресурс. Наприклад, тут можна окремо подивитися на Git Operations, Actions, Pull Requests, Copilot тощо.

Для кожного компонента сайт рахує uptime та сумарний downtime, а ще показує календар інцидентів, їхню серйозність, час відновлення, найгірші дні та розподіл проблем за днями тижня.

Так, станом на зараз ресурс нарахував 1128 інцидентів із березня 2016 року. За останні три місяці GitHub мав у середньому 24,7 випадків на місяць. Найгіршим місяцем став лютий 2026 року з 37 інцидентами. Так, лише 9 лютого GitHub зафіксував одразу сім окремих проблем.

А якщо рахувати не кількість проблем, а сумарний downtime, антирекорд належить 16 квітня 2025 року, коли пов’язані з GitHub сервіси мали загалом понад добу простою. Водночас найдовший період без проблем склав лише вісім днів.

Цікаво, що найчастіше GitHub має проблеми середами та вівторками — 247 інцидентів (22%) та 241 (21%) інцидентів відповідно. А от вихідні очікувано виходять значно спокійнішими.

За весь час 81% труднощів були незначними, 16% — суттєвими та близько 3% — критичними.

Найнижчий показник uptime має Copilot, далі йдуть Actions та Pull Requests. Водночас це не означає, що весь GitHub був недоступний протягом зазначеного часу, оскільки сайт рахує проблеми окремо для кожного сервісу, а один інцидент може зачіпати лише частину платформи.

Нагадаю, нещодавно GitHub пережив масштабний збій, який зачепив вебверсію, API, Actions, Pull Requests, Copilot та інші сервіси. На піку близько 20% запитів до web/API завершувалися помилками, а весь інцидент тривав майже вісім годин. У постмортемі пояснили, що все почалося з непоміченого ботлнеку в Istio, а повторні запити та баг у VS Code, який удесятеро збільшив навантаження на Copilot, додатково затягнули відновлення.