GitHub, най-голямата платформа за хостване на код в света, се бори със сериозно прекъсване на услугите, което започна около 13:40 UTC на 17 август 2026 г. Това остави разработчици, предприятия и DevOps екипи в затруднено положение, тъй като основни услуги, включително Pull Requests, Issues, Actions, Webhooks и Copilot, продължават да изпитват влошена производителност повече от два часа след началото на инцидента.

Според официалната страница за състоянието на GitHub, платформата в момента отчита нива на грешки от приблизително 20% при общото уеб потребление и API трафика – цифра, която остава стабилна, докато инженерите работят по мерки за смекчаване на последиците.

Щетите са много по-сериозни за конкретни функции: изтеглянето на архиви и изтеглянето на необработено съдържание от хранилищата (raw repository content) са неуспешни с около 50% процент на грешки, което на практика намалява надеждността на тези операции наполовина за времетраенето на инцидента.

Корпоративните клиенти са изправени пред допълнително затруднение, тъй като SAML и OIDC автентикацията, SCIM предоставянето на ресурси (provisioning) и Team Sync са маркирани като засегнати, което застрашава достъпа чрез единен вход (single sign-on) за организации, разчитащи на GitHub Enterprise Cloud.

Вълнообразният ефект от срива е по-скоро постепенен, отколкото внезапен. GitHub първо призна за „засегната производителност на някои услуги на GitHub“ в 13:40 UTC, а след това потвърди влошеното състояние на API заявките, Actions и Webhooks в рамките на следващия час.

Issues и Pull Requests бяха добавени малко след това, а Copilot се присъедини към списъка със засегнати компоненти около 14:31 UTC. Независимата услуга за мониторинг Downdetector съобщи, че оплакванията от потребители са започнали да нарастват рязко около 13:30 UTC, което съвпада с хронологията на GitHub, докато Microsoft, компанията майка на GitHub, публично потвърди, че платформата изпитва проблеми в световен мащаб.

Според последното актуализиране на състоянието от GitHub, инженерният екип заявява, че „в момента прилага мерки за смекчаване на последиците въз основа на разследването ни до момента и следи за подобрение“, но първопричината все още не е публично оповестена. Този модел на повтарящи се, ескалиращи актуализации на състоянието без ясен виновник предполага, че основният проблем може да е свързан с претоварване на инфраструктурно ниво или каскаден срив в зависими услуги, а не с изолирана софтуерна грешка, въпреки че GitHub не е потвърдил конкретни детайли.

За отделните разработчици практическите последици означават, че заявките за сливане (pull requests) може да не успеят да се слеят, CI/CD тръбопроводите (pipelines), изградени върху Actions, могат да спрат или да дадат грешка в средата на спринта. Екипите, които зависят от уебкукички (webhooks) за автоматизация – като задействане на внедрявания или известяване в чат инструменти – трябва да очакват забавени или отпаднали събития, докато платформата се стабилизира.

В момента няма решение, което потребителите могат да приложат сами; на засегнатите екипи се препоръчва да отложат некритичните операции с хранилищата и да следят директно страницата за състоянието на GitHub за актуализации в реално време, вместо да разчитат на кеширани табла за управление.

Този инцидент се случва само няколко месеца след като GitHub въведе по-прозрачна рамка за отчитане на състоянието през април 2026 г., която въведе детайлни нива на сериозност и 90-дневни показатели за време на работа (uptime) за всяка отделна услуга, което осигурява на днешния срив необичайно подробна видимост в сравнение с минали прекъсвания.

GitHub все още не е предоставил очаквано време за разрешаване на проблема, като се очаква компанията да публикува пълен анализ на инцидента (postmortem), след като услугите бъдат възстановени, в съответствие с практиката си за месечни доклади за наличност.