GitHub lag am 17. August 7 Stunden und 47 Minuten in Teilen still. Technikchef Vlad Fedorov nennt als Ursache keinen Programmfehler, sondern eine Komponente im Rechenzentrum Central US, die dem Andrang nicht mehr folgte. Auch Kunden mit EU-Datenresidenz traf der Ausfall, weil ihre Actions-Workflows an Bausteinen von GitHub.com hängen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Der Ausfall begann um 13:28 Uhr UTC und endete um 21:15 Uhr. Dazwischen scheiterte rund jeder fünfte Aufruf im Web und in der API, bei Archiv-Downloads etwa jeder zweite. Hinter der Störung steht eine Wachstumskurve, die GitHub selbst offenlegt.
Das Wichtigste in Kürze
- 7 Stunden 47 Minuten Störung am 17. August, betroffen waren Issues, Pull Requests, APIs, Actions und Copilot.
- Als Ursache benennt GitHub fehlende Kapazität, nicht Code oder Konfiguration.
- Die monatlichen Commits stiegen seit April von 1,4 auf 2,9 Milliarden, die Actions-Läufe auf über 100 Millionen.
- Finanzunternehmen brauchen laut BaFin eine Ausstiegsstrategie für kritische IKT-Dienstleister.
Welche Dienste fielen am 17. August aus?
Von 13:28 bis 21:15 Uhr UTC meldete GitHub erhöhte Fehler und Latenzen bei Issues, Pull Requests, APIs, Actions und Copilot. In der Spitze lag die Fehlerrate im Web und in der API bei rund 20 Prozent, bei Archiv- und Rohdaten-Downloads bei rund 50 Prozent.[1]
Mitbetroffen war die Anmeldung über SAML und OIDC, dazu SCIM und Team Sync. Die meisten Dienste liefen ab 16:36 Uhr wieder, Actions blieb bis gegen 18:03 Uhr gestört, die Copilot-Anmeldung bis zum Ende der Störung.[1]
Eine Quote von 20 Prozent klingt nach Teilausfall, wirkt am Bildschirm aber wie ein Totalausfall. Eine einzige Seitenansicht löst ein Dutzend Anfragen aus; scheitert davon eine, bricht der ganze Vorgang ab.
Warum kippt die Plattform, statt langsamer zu werden?
Eine kritische Komponente im Rechenzentrum Central US skalierte nicht mit dem neuen Verkehrsrekord. Chief Technology Officer Vlad Fedorov ordnet beide großen Störungen im August als Kapazitätsprobleme ein.[2]
Jenseits dieser Grenze verstärkt sich die Last selbst. Erst nachdem GitHub die Wiederholversuche für Authentifizierungs-Token teilweise abschaltete, gingen die sporadischen Anmeldefehler zurück.[1] Fedorov kündigt einheitliche Grenzen und Budgets für solche Wiederholversuche an.[2]
Der Vorfall vom 6. August folgte demselben Muster. GitHub Actions lag gut neun Stunden lahm, in der Spitze scheiterten 71 Prozent aller Workflow-Läufe an Infrastrukturfehlern. Runner blockierten sich gegenseitig, weil sie längst ungültige Jobs immer wieder anforderten.[4]
Maschinelle Zugriffe bringen auch kleinere Projekte an die Grenze. Das Gentoo-Team nahm im August den eigenen Bugtracker vom Netz, weil KI-Scraper die Server überlasteten. Als Ausweichquartier für Quellcode entsteht daneben gerade Origin, das Code-Hosting von Cursor.
Bei GitHub hat sich die Zahl der Commits seit April verdoppelt, die Kapazität kam erst danach. Entscheider sollten die eigene Build-Pipeline als Fremdressource behandeln, die auch acht Stunden ausfallen kann.
— Markus Seyfferth, Chefredakteur Dr. Web
GitHub.com am 17. August 2026
Was heißt das für Entwicklungsteams im DACH-Raum?
Der Ausfall traf auch Kunden mit EU-Datenresidenz. Actions-Workflows in GitHub Enterprise Cloud with Data Residency greifen auf öffentliche Schritt-Definitionen von GitHub.com zurück und standen deshalb ebenfalls still.[1]
Für Finanzunternehmen ist diese Abhängigkeit reguliert. Die BaFin verlangt unter der EU-Verordnung DORA ein Informationsregister aller IKT-Vertragsbeziehungen sowie eine Ausstiegsstrategie für kritische oder wichtige Funktionen.[3]
Praktisch beginnt die Vorsorge beim Quellcode. Ein aktueller Spiegel der Repositories außerhalb von GitHub hält ihn erreichbar, etwa auf einer eigenen GitLab-Instanz. Begrenzte Wiederholversuche in den eigenen Runnern sorgen dafür, dass die Störung sich nicht zusätzlich in die Länge zieht.
Der Freigabeprozess muss zudem einen Arbeitstag ohne Pull Requests überstehen. Ein eigenes Monitoring der wichtigen Endpunkte warnt außerdem früher als die Statusseite des Anbieters.
Quellen
[1] GitHub Status: „Incident with GitHub.com“, 17. August 2026
[2] Vlad Fedorov, GitHub: „The August 17 outage and the work ahead“
[3] BaFin: „Management des IKT-Drittparteienrisikos“
[4] GitHub Status: „Incident with Actions“, 6. August 2026
Mehr Newshunger?
- Cursor hostet jetzt Quellcode: Origin startet drei Tage nach dem Verkauf an SpaceX
- GitLab schließt die Lücke, die öffentliche Projekte ohne Anmeldung löscht
- Gentoo nimmt den Bugtracker vom Netz: KI-Scraper überlasten den Server
- Ein Autofix von GitHub Copilot öffnete den Zugang zu Snowflakes internem Jira
- Uptimepage: Uptime-Monitoring und Statusseite aus einem Open-Source-Binary
