GitHub Actions räumt auf: CI-Historie hängt ab Oktober an der Aufbewahrungsfrist

Am 27. August hat GitHub im Changelog eine Änderung angekündigt, die auf den ersten Blick nach Verwaltungskram aussieht, aber jedem CI/CD-Team ins Pflichtenheft gehört: Ab dem 1. Oktober 2026 unterliegen Checks, Workflow-Runs und Commit-Status derselben Aufbewahrungsfrist wie Artefakte und Logs. Bislang blieben diese Metadaten mehr als 400 Tage erhalten, unabhängig davon, wie kurz die Retention für Artefakte eingestellt war. Das ändert sich jetzt, und wer seine CI-Historie für Audits, Debugging oder einfach aus Nostalgie braucht, sollte sich den Stichtag im Kalender markieren.

Was am 1. Oktober an der GitHub Actions Retention ändert

Die Logik bisher war seltsam inkonsistent: Ein Artefakt konnte nach 30 Tagen verschwinden, während der zugehörige Workflow-Run mit grünem oder rotem Haken noch über ein Jahr später in der Historie auftauchte. Diese Asymmetrie räumt GitHub jetzt auf. Checks, Workflow-Runs und Statusmeldungen laufen künftig nach derselben Uhr wie die Actions-Retention für Artefakte und Logs. Wer seine Retention-Policy auf 30 Tage gesetzt hat, weil Artefakte Speicherplatz kosten, verliert ab Oktober auch die Laufzeitgeschichte seiner Pipelines nach 30 Tagen – nicht erst nach über einem Jahr.

Technisch betrachtet ist das eine Vereinheitlichung, keine neue Funktion. GitHub führt keinen neuen Mechanismus ein, sondern koppelt vorhandene Datentypen an eine bereits existierende Einstellung. Für Teams, die ihre Retention nie bewusst konfiguriert haben und auf dem Standardwert sitzen, ändert sich praktisch trotzdem viel, weil die GitHub Actions Retention plötzlich Bereiche betrifft, an die vorher niemand gedacht hat. Ähnliche Governance-Fragen rund um automatisierte Abläufe tauchen derzeit ohnehin häufiger auf, etwa wenn es um agentenbasierte Automation bei Issues geht, wo ebenfalls plötzlich mehr Verantwortung bei den Teams selbst landet, als es die Ankündigung zunächst vermuten lässt.

Fünf Datenarten, eine Uhr: Wie GitHub Checks archivieren jetzt funktioniert

Nach Einschätzung von CloudNinjas vereinheitlicht die Änderung fünf verschiedene Datenarten unter einer einzigen Aufbewahrungsregel und vereinfacht damit Cleanup und Kostenmanagement. Das ist die Perspektive von GitHub-Seite: weniger Sonderfälle, weniger Datenmüll, der ewig in den Servern liegt, ohne dass jemand ihn abgerufen hätte.

Wichtig ist dabei eine Unterscheidung, die in der Diskussion leicht untergeht: Artefakte und Logs sind abrechenbarer Speicher, Checks, Workflow-Runs und Commit-Status sind das nicht. Die Änderung bedeutet nicht, dass Sie künftig für alte Pull-Request-Checks bezahlen. Sie bedeutet, dass diese Metadaten jetzt an dieselbe Löschfrist gekoppelt sind wie der kostenpflichtige Speicher – ohne selbst zu den Speicherkosten beizutragen. Wer also GitHub Actions Retention nur unter dem Kostenaspekt betrachtet hat, muss jetzt auch den Datenaspekt mitdenken. Wer Artefakte aus Kostengründen aggressiv kurz hält, bekommt jetzt eine kürzere Workflow Runs Aufbewahrung gleich mit dazu, ob er wollte oder nicht.

90 Tage als Obergrenze – aber nur für öffentliche Repositories

Für öffentliche Repositories nennt GitHub in der Ankündigung eine feste Obergrenze: maximal 90 Tage Aufbewahrung für diese Daten. Das betrifft potenziell jedes Open-Source-Projekt, dessen Maintainer nie eine explizite Retention-Policy gesetzt haben, weil die Voreinstellung ausreichend erschien.

Für private Repositories macht die Ankündigung keine pauschale Aussage in dieser Form. Hier bleibt offenbar mehr Spielraum, abhängig davon, welche Retention-Policy in der jeweiligen Organisation konfiguriert ist. Das ist ein Detail, das man nicht überlesen sollte: Nicht jedes Repository landet automatisch bei 90 Tagen, aber jedes öffentliche Repository tut es, wenn niemand eingreift. Für Maintainer von Open-Source-Projekten mit jahrelanger Commit-Historie ist das der eigentliche Knackpunkt der ganzen Ankündigung. Wer als Betreiber größerer Infrastruktur ohnehin regelmäßig mit Patch- und Support-Zyklen zu tun hat, kennt das Grundproblem aus einem anderen Kontext: Auch bei aktuellen Patches für Support-Bundles zeigt sich immer wieder, wie schnell Daten, die man für dauerhaft archiviert hielt, tatsächlich an feste Fristen gebunden sind.

Warum die Workflow Runs Aufbewahrung für den CI Audit Trail zählt

Ein Workflow-Run ist mehr als eine grüne Häkchen-Grafik. Er dokumentiert, welcher Commit zu welchem Zeitpunkt welche Tests durchlaufen hat, mit welchem Ergebnis, auf welchem Runner, mit welcher Laufzeit. Genau diese Informationen bilden den CI Audit Trail, auf den Teams zurückgreifen, wenn sie Monate später rekonstruieren müssen, warum ein Release fehlgeschlagen ist oder ob ein bestimmter Sicherheitsfix tatsächlich getestet wurde, bevor er gemergt wurde.

Checks sind dabei besonders sensibel, weil sie an Pull Requests hängen. Wenn ein Reviewer vor Monaten einen Merge freigegeben hat, weil alle Checks grün waren, verschwindet dieser Nachweis nach Ablauf der Frist einfach. Für interne Audit-Anforderungen, für Compliance-Nachweise gegenüber Kunden oder für die simple Frage „Warum genau haben wir damals diesen Build zugelassen?“ ist das ein Problem. Ich finde, genau hier zeigt sich, dass GitHub eine technische Vereinfachung umsetzt, ohne die praktischen Folgen für Audit- und Debug-Zwecke besonders laut zu kommunizieren. Die Meldung liest sich wie ein Housekeeping-Hinweis, hat aber für manche Teams die Tragweite einer Compliance-Frage.

Besonders unangenehm wird es dort, wo CI-Ergebnisse als Beleg für externe Prüfungen dienen. Manche Unternehmen müssen gegenüber Kunden oder Aufsichtsbehörden nachweisen, dass bestimmte Softwarestände geprüft und freigegeben wurden. Bislang konnte man dafür einfach auf die GitHub-Oberfläche verweisen und den entsprechenden Workflow-Run zeigen. Fällt dieser Run nach 90 Tagen oder nach der intern konfigurierten Frist weg, bricht dieser einfache Nachweisweg weg, und man braucht stattdessen eine eigene, unabhängige Dokumentation. Das ist kein Weltuntergang, aber es ist ein zusätzlicher Prozessschritt, den vorher niemand einplanen musste, weil die Plattform ihn quasi kostenlos mitgeliefert hat.

Der Haken: Ohne Export ist die Historie unwiderruflich weg

Der unangenehmste Satz in der ganzen Ankündigung betrifft nicht den Stichtag, sondern die Endgültigkeit. GitHub weist ausdrücklich darauf hin, dass eine spätere Erhöhung der Retention bereits entfernte Daten nicht wiederherstellt. Wer im November merkt, dass er die Frist zu kurz eingestellt hatte, und die Einstellung großzügiger macht, bekommt die im Oktober gelöschten Checks und Runs trotzdem nicht zurück. Es gibt keinen Papierkorb, keine Wiederherstellungsfunktion, keinen Support-Ticket-Weg, der das rückgängig macht.

Deshalb empfiehlt GitHub in der Changelog-Ankündigung ausdrücklich, benötigte Daten vor Ablauf der konfigurierten Frist zu exportieren oder zu archivieren. Das ist kein netter Zusatzhinweis, sondern die einzige Möglichkeit, historische CI-Daten über die neue Frist hinaus zu erhalten. Wer jetzt nichts unternimmt, verlässt sich stillschweigend darauf, dass ihm die eigene Historie nach 90 Tagen egal ist – bei öffentlichen Repositories ist das ab Oktober schlicht die Realität, wenn niemand vorher exportiert. Ähnliche Verantwortungsverschiebungen sieht man derzeit auch bei anderen Automatisierungsfunktionen rund um GitHub, etwa wenn Cloud-Agenten wie Copilot in externe Tools integriert werden und Teams sich neu überlegen müssen, welche Daten wo entstehen und wie lange sie tatsächlich verfügbar bleiben sollen.

Ein Blick auf andere CI-Umgebungen: Ist GitHub hier wirklich strenger?

Wer sich fragt, ob diese Änderung eine GitHub-Eigenheit ist oder ob andere CI-Plattformen ähnliche Grenzen ziehen, landet schnell bei einer grundsätzlichen Erkenntnis: Speicher kostet überall, und irgendwann muss jede Plattform entscheiden, wie lange Metadaten aufbewahrt werden, ohne dass die Kosten aus dem Ruder laufen. Selbstgehostete Lösungen wie eigene Jenkins- oder GitLab-CI-Instanzen legen diese Entscheidung vollständig in die Hand der Betreiber. Wer dort mehr Speicher bereitstellt oder eine externe Datenbank für Build-Historien anbindet, kann die Aufbewahrung im Prinzip beliebig verlängern, muss dafür aber auch selbst für Infrastruktur, Wartung und Kosten aufkommen.

Cloud-basierte CI-Dienste wie GitHub Actions stehen dagegen vor einem anderen Zielkonflikt: Sie müssen für Millionen Repositories gleichzeitig eine sinnvolle Balance zwischen Nutzerfreundlichkeit, Speicherkosten und Datenschutzanforderungen finden. Eine zentrale, einheitliche Regel ist aus Betreibersicht einfacher zu kommunizieren und zu warten als hunderte Sonderfälle. Das erklärt, warum GitHub sich für eine harte Kopplung an die bestehende Artefakt-Retention entschieden hat, statt für Checks und Workflow-Runs eine eigene, womöglich großzügigere Frist zu definieren. Ob das im Vergleich zu anderen Anbietern nun strenger oder großzügiger ist, lässt sich ohne einen direkten, aktuellen Vergleich der jeweiligen Standardeinstellungen nicht seriös behaupten – entscheidend ist ohnehin weniger der Vergleich zwischen Plattformen als die Frage, ob die eigene Organisation ihre Anforderungen kennt und danach konfiguriert.

Ein Praxisszenario: Wie sich die Änderung im Alltag auswirken könnte

Um sich die Tragweite besser vorzustellen, hilft ein hypothetisches Beispiel. Stellen wir uns ein kleines Entwicklerteam vor, das ein öffentliches Open-Source-Tool pflegt und nie eine eigene Retention-Policy gesetzt hat, weil das Thema schlicht nie Priorität hatte. Bislang konnte das Team bei Bug-Reports, die sich auf ältere Versionen bezogen, einfach in der Actions-Historie nachsehen, welcher Workflow-Run zu welchem Tag welches Ergebnis gebracht hat. Nach dem 1. Oktober würde genau dieser Rückgriff nach 90 Tagen nicht mehr möglich sein, weil die öffentliche Obergrenze automatisch greift.

Für ein Team, das gelegentlich Support für ältere Versionen leistet, wäre die Konsequenz überschaubar, aber spürbar: Statt in der Oberfläche nachzuschauen, müsste jemand vorher aktiv einen Export einrichten, der die relevanten Daten regelmäßig in ein eigenes Archiv überträgt, etwa als einfache Log-Datei oder als Eintrag in einer eigenen Datenbank. Das ist technisch keine große Hürde, aber es erfordert, dass jemand im Team das Thema überhaupt auf dem Schirm hat, bevor die Frist verstreicht. Genau an dieser Stelle unterscheidet sich ein gut vorbereitetes Team von einem, das die Änderung erst bemerkt, wenn ein Debugging-Versuch plötzlich ins Leere läuft, weil die gesuchten Daten schlicht nicht mehr existieren. Ein solches Szenario ist kein Einzelfall, sondern dürfte sich in den kommenden Monaten in ganz ähnlicher Form bei vielen kleineren und mittleren Projekten wiederholen, die Actions eher nebenbei nutzen, ohne sich intensiv mit den Einstellungen auseinanderzusetzen.

Was Sie jetzt konkret tun sollten

Die Änderung tritt am 1. Oktober 2026 in Kraft. Bis dahin bleibt Zeit, die eigene Konfiguration zu prüfen und gegebenenfalls zu handeln. Ein paar Schritte, die sich lohnen:

• Prüfen Sie die aktuell konfigurierte Actions Retention in den Repository- oder Organisationseinstellungen – viele Teams laufen unbemerkt auf dem Standardwert.
• Identifizieren Sie öffentliche Repositories mit langer, für Sie relevanter CI-Historie und exportieren Sie Workflow-Runs, Checks und Status-Daten, bevor die 90-Tage-Obergrenze greift.
• Wenn Sie Audit- oder Debug-Daten dauerhaft brauchen, richten Sie einen regelmäßigen Export in ein externes Archiv ein, statt sich auf die GitHub-eigene Aufbewahrung zu verlassen.
• Dokumentieren Sie intern, welche Retention-Policy für welches Repository gilt – gerade bei mehreren Organisationen und Teams verliert man sonst schnell den Überblick.
• Sprechen Sie mit Ihrem Compliance- oder Audit-Verantwortlichen, ob CI-Ergebnisse Teil eines Nachweiszeitraums sind, der über die neue Frist hinausgeht, und klären Sie frühzeitig, wer für den Export zuständig ist.
• Testen Sie den Export-Prozess einmal exemplarisch, bevor Sie sich darauf verlassen – ein Skript, das nie ausprobiert wurde, hilft im Ernstfall wenig.

Wer GitHub Actions als reine Build-Pipeline nutzt, wird die Umstellung kaum spüren. Wer Actions-Daten aber als Teil eines längeren Nachweiszeitraums braucht, etwa weil interne Richtlinien eine bestimmte Dokumentationsdauer verlangen, sollte die Änderung nicht erst im Oktober zur Kenntnis nehmen. Erst vor wenigen Tagen mussten Teams ihre Windows-ARM64-Runner auf ein neues Visual-Studio-Image umstellen – GitHub Actions verändert sich derzeit an mehreren Stellen gleichzeitig, und wer die Changelog-Einträge nicht mitliest, verpasst leicht mehr als nur diese eine Frist.

Einordnung: Aufräumen mit Kollateralschaden

Aus Betreiber-Sicht ist die Vereinheitlichung nachvollziehbar. Fünf verschiedene Datentypen mit fünf potenziell verschiedenen Lebenszyklen zu pflegen, ist Wartungsaufwand, den niemand freiwillig länger als nötig trägt. Eine einzige Retention-Uhr für Artefakte, Logs, Checks, Workflow-Runs und Status ist aus Infrastruktursicht schlicht sauberer.

Nur: Genau diese Sauberkeit verschiebt Verantwortung Richtung Nutzer. Bisher war die lange Aufbewahrung von Checks und Runs ein kostenloser Nebeneffekt der bisherigen Architektur – niemand musste sich aktiv darum kümmern, dass Metadaten über ein Jahr lang abrufbar blieben. Jetzt braucht es aktives Handeln, um diesen Zustand zu erhalten. Ist eine feste 90-Tage-Grenze für öffentliche Repositories mit teils jahrelanger Projektgeschichte tatsächlich die richtige Balance zwischen Aufräumen und Nachvollziehbarkeit? Ich habe daran meine Zweifel, gerade weil Open-Source-Maintainer selten Zeit haben, sich proaktiv mit Retention-Einstellungen zu beschäftigen, bevor ein Changelog-Eintrag sie dazu zwingt.

Man kann der Änderung natürlich auch etwas Positives abgewinnen: Sie zwingt Teams, sich überhaupt einmal bewusst mit ihrer Retention-Konfiguration auseinanderzusetzen, statt sich auf implizite Standardwerte zu verlassen, die ohnehin niemand aktiv gewählt hatte. Wer die Umstellung als Anlass nimmt, eine durchdachte Archivierungsstrategie aufzusetzen, gewinnt am Ende mehr Kontrolle über die eigenen Daten, als es die bisherige, eher zufällige lange Aufbewahrung je geboten hat. Der Unterschied liegt darin, ob man diese Kontrolle freiwillig übernimmt oder erst reagiert, wenn die Lücke bereits entstanden ist.

Für Self-Hosting-affine Teams, die ohnehin eigene Runner und eigene Log-Pipelines betreiben, ist die Konsequenz simpel: Wer CI-Daten dauerhaft braucht, exportiert sie in eine eigene, unabhängige Ablage und macht sich nicht von GitHubs Aufbewahrungslogik abhängig. Das kostet etwas Automatisierungsaufwand, entkoppelt aber die eigene Dokumentationspflicht von einer fremden Plattformentscheidung – und genau das ist am Ende die robustere Architektur, unabhängig davon, wie GitHub seine Retention künftig noch anpasst.

Was bleibt? Der Stichtag steht fest, die Konsequenz ist klar dokumentiert, und die Verantwortung liegt jetzt bei den Teams selbst. Wer im Oktober noch nicht exportiert hat, was er behalten will, wird die Lücke in der eigenen CI-Historie erst dann bemerken, wenn er sie tatsächlich braucht – und dann ist es zu spät.

Die belegten Angaben dokumentiert die Changelog-Ankündigung von GitHub.