GitHub Actions і Pages: години зниженої доступності

GitHub Actions працював зі зниженою доступністю протягом більшої частини 6 серпня 2026 року: робочі процеси або збоїли, або годинами стояли в чергах, а наслідки зачепили GitHub Pages, функції Copilot і корпоративні інструменти міграції. Сторінка статусу GitHub фіксує інцидент з 15:05 UTC 6 серпня до 00:14 UTC наступного дня.

Що сталося

За післяінцидентним звітом GitHub, тригером став рутинний деплой у внутрішній сервіс Actions, який обробляє події та створює завдання. Деплой оголив наявну слабкість у потужності й паралелізмі: коли pod'и замінювалися, залишкова потужність вичерпалася, сервіси падали, і збій каскадом поширився на кілька кластерів та суміжні сервіси. На піку 71 відсоток запусків робочих процесів зазнав інфраструктурних збоїв, а 75 відсотків решти затрималися більш ніж на п'ять хвилин. Постраждали користувачі як хостованих GitHub, так і власних (self-hosted) раннерів.

Другий баг і години дроселювання

Інженери розширили потужності, пригальмували роботу, яку запускають webhook'и, щоб система могла відновитися, і додали ресурси для розбору черг; основні сервіси повернулися близько 17:00 UTC. Але вже виявився другий дефект: прихований баг у сервісі призначення завдань призводив до того, що раннери отримували неактуальні завдання й застрягали, повторюючи їх. У найгірший момент виконувалося приблизно 30–40 відсотків завдань у черзі; після виправлень частка успішних запусків зросла до 97, а згодом 99 відсотків, і накопичені черги розібралися за ніч.

Наслідки

Відновлення залишило по собі хвіст. Частина pod'ів Actions Runner Controller застрягла в простої й потребувала ручного втручання; тимчасове виправлення, застосоване під час інциденту, довелося відкотити, а автоматичне відновлення обіцяють у наступних випусках Runner і ARC. GitHub також попередив, що події push і pull request, втрачені під час збою, не відтворюються автоматично, тож деякі робочі процеси доведеться перезапустити вручну. Щоб це не повторилося, компанія вдосконалює контролі деплою та потужностей, моніторинг умов, що передували інциденту, і стійкість черг та призначення завдань раннерам.