GitHub fällt wieder aus: Mirrors, Alternativen und wie Sie online bleiben

Wenn Sie in letzter Zeit einen Branch pushen, eine CI-Pipeline starten oder ein Paket installieren wollten und auf eine Fehlerseite gestoßen sind, waren Sie nicht allein. GitHub hatte zuletzt deutlich mehr Ausfälle und Performance-Probleme als gewöhnlich, und für eine Plattform im Zentrum der modernen Softwareentwicklung spürt die gesamte Branche jede Minute Downtime.

Dieser Beitrag ist keine Anklage. Vor allem anderen ist er ein Dankeschön. Und dann, weil wir alle noch etwas ausliefern müssen, ein praktischer Leitfaden zu GitHub-Alternativen, Git Mirrors und dazu, wie Sie sicherstellen, dass der nächste Ausfall Ihr Projekt nicht stoppt — und von Ihren Nutzern nicht unbemerkt bleibt.

Danke, GitHub

Man vergisst leicht, wie viel eine einzige Plattform verändert hat. GitHub hat aus Code-Hosting eine Community gemacht und ist seit fast zwei Jahrzehnten das Standardzuhause von Open Source. Einiges davon nehmen wir heute als selbstverständlich hin:

• Pull Requests und Social Coding — der Workflow, den eine ganze Entwicklergeneration auf GitHub gelernt hat.
• Ein Zuhause für Millionen Projekte — von Wochenend-Experimenten bis zur Infrastruktur des Internets.
• GitHub Actions, Pages und Packages — eine komplette Toolchain, aus der kleine Teams riesig wirkten.
• Netzwerkeffekte — Stars, Issues, Discussions und README-Kultur, die das Entdecken von Software zu einem Vergnügen machten.

Nichts davon verschwindet wegen ein paar schlechter Tage. Ausfälle treffen jeden; je erfolgreicher eine Plattform, desto mehr Menschen spüren ihren schlechten Tag. Die gesunde Reaktion ist keine Wut. Es ist Dankbarkeit — plus ein Backup-Plan. Und ehrlich gesagt macht GitHub es leicht, seine schlechten Tage über die eigene Status-Seite zu verfolgen. Aber Sie sollten sie nicht selbst prüfen müssen.

Was wirklich kaputtgeht, wenn GitHub down ist

github.com hat einen schlechten Tag, ist der Wirkungsradius größer als gedacht:

• Clone, Push und Pull Requests — die täglichen Grundlagen stehen still.
• CI/CD-Pipelines (Actions) — Builds bleiben in der Warteschlange oder schlagen fehl, Releases verzögern sich.
• GitHub Pages — Dokumentations- und Marketingseiten werden dunkel.
• Paketinstallationen — Abhängigkeiten, die GitHub-Endpunkte abrufen, beginnen zu scheitern.
• Webhooks und Integrationen — Events verzögern sich oder gehen verloren und brechen Automatisierungen still.

Wenn Ihr Release-Prozess, Ihre Dokumentation oder Ihr Produkt eines davon berührt, ist Ihre Uptime jetzt an die Uptime von GitHub gekoppelt. Dieses Risiko lässt sich wirklich reduzieren.

Git Mirrors: Ihre erste Verteidigungslinie

Ein Git Mirror ist eine vollständige, kontinuierlich aktualisierte Kopie Ihres Repositorys auf einem anderen Host. Ein Mirror ist keine Migration und kein Protest — er ist Redundanz. Hat GitHub einen schlechten Tag, leben Ihre Historie, Branches und Tags woanders weiter.

1. Wählen Sie ein zweites Zuhause. GitLab, Codeberg oder ein selbst gehostetes Gitea oder Forgejo funktionieren alle hervorragend.
2. Pushen Sie alles einmal: klonen Sie mit git clone --mirror, dann führen Sie git push --mirror gegen das neue Remote aus.
3. Halten Sie es synchron: entweder ein zweites Remote hinzufügen (git remote add mirror <url>) und zu beiden pushen, oder git push --mirror aus einem geplanten Job ausführen — ein stündlicher Cron-Eintrag reicht für die meisten Teams.
4. Oder lassen Sie die Kopie sich selbst pflegen: GitLab, Gitea und Forgejo können Pull-Mirrors von GitHub nach Zeitplan anlegen, ganz ohne Cron.
5. Prüfen Sie den Mirror gelegentlich. Ein nie getesteter Mirror ist ein falsches Sicherheitsgefühl.

Ein Mirror gibt Ihnen kein zweites CI oder Issue-Tracking, aber er schützt das Wertvollste, was Sie besitzen: Ihren Code und seine Historie.

GitHub-Alternativen, die man kennen sollte

Sie müssen GitHub nicht verlassen, um auf einen Regentag vorbereitet zu sein. Die Alternativen zu kennen — und vielleicht einen Mirror auf einer davon zu halten — ist einfach gutes Engineering. Jede dieser Plattformen hat echtes Vertrauen der Community verdient:

• GitLab — eine komplette DevOps-Plattform mit integrierter CI/CD, Container-Registry und erstklassigem Repository-Mirroring in beide Richtungen. Der natürlichste Plan B für Teams.
• Codeberg — eine gemeinnützige, von der Community betriebene Plattform, angetrieben von Forgejo. Ein wirklich unabhängiges Zuhause für freie und Open-Source-Software.
• Sourcehut — minimal, schnell und E-Mail-basiert. Ein erfrischend unprätentiöser Blick auf Forge-Tooling.
• Gitea und Forgejo — leichtgewichtige Open-Source-Forges für das Self-Hosting. Volle Kontrolle, kleiner Fußabdruck, integrierte Mirror-Unterstützung.
• Bitbucket — die etablierte Atlassian-Option mit tiefer Jira-Integration.

Das Ziel ist nicht, GitHub aufzugeben. Es ist, mit gutem Gewissen sagen zu können, dass man nie vollständig von ihm abhängig war.

Entkoppeln, was Sie entkoppeln können

Mirrors schützen Ihren Code. Aber Downtime tut am meisten weh, wenn alles andere am selben Host hängt. Verteilen Sie die Last:

• Dokumentation und Landingpages — servieren Sie sie nicht nur über GitHub Pages. Betreiben Sie sie wie die Production-Seiten, die sie sind.
• Pakete — veröffentlichen Sie in mehr als einer Registry, etwa npm plus eine private oder zweite Plattform-Registry.
• Releases — halten Sie Artefakte zusätzlich zu GitHub Releases auf Ihrem eigenen Storage oder CDN.
• CI — eine zweite Pipeline auf GitLab oder eigenen Runnern kann übernehmen, wenn Actions down ist.
• Badges und Deep-Links — wenn Ihre README oder Website raw.githubusercontent.com referenziert, behandeln Sie diese URL wie eine Abhängigkeit und überwachen Sie sie entsprechend.

Wissen Sie es, bevor Ihre Nutzer es tun

Von einem Ausfall über Social Media zu hören heißt, zu spät zu sein. Die Lösung ist langweilig und wirksam: Überwachen Sie die Dinge, von denen Sie abhängen — GitHub selbst, Ihre Pages-Seite, Ihre Clone-Endpunkte und natürlich Ihr eigenes Produkt.

Genau dafür haben wir isthisthing.online gebaut. Fügen Sie HTTP-, TCP- oder Ping-Monitors für jeden Hop zwischen Ihnen und Ihren Nutzern hinzu: github.com, api.github.com, Ihre GitHub-Pages-URL und Ihre Production-Endpunkte. Checks laufen von bis zu 10 globalen Standorten in Intervallen bis hinunter zu 30 Sekunden, und Alerts landen im Moment der Verschlechterung in Slack, Microsoft Teams, Discord oder — via Webhooks — überall sonst.

Wenn GitHub down ist, sagt Ihnen Ihr Monitoring innerhalb von Sekunden, ob es GitHub oder Ihr eigener Stack ist — dann wechseln Sie zu Ihrem Mirror, drehen einen DNS-Eintrag oder hören einfach auf, den Ausfall anderer zu debuggen.

Und wenn Sie selbst einen schlechten Tag haben, hält eine automatisch aktualisierte Status Page Ihre Nutzer informiert, statt sie Ihre Support-Inbox aktualisieren zu lassen.

Eine praktische Resilienz-Checkliste

1. Erstellen Sie einen Mirror jedes kritischen Repositorys und halten Sie ihn synchron.
2. Fügen Sie für Ihre wichtigsten Projekte eine zweite CI-Pipeline hinzu.
3. Veröffentlichen Sie Pakete und Release-Artefakte an mehr als einem Ort.
4. Hängen Sie Dokumentations- und Marketingseiten nicht von einer einzelnen Plattform ab.
5. Überwachen Sie github.com, api.github.com, Ihre Pages-URLs und Ihre eigenen Endpunkte mit schnellen Checks.
6. Leiten Sie Alerts an Slack, Teams oder Discord weiter, damit die richtigen Menschen es zuerst hören.
7. Veröffentlichen Sie eine öffentliche Status-Seite, damit Ihre Nutzer nie raten müssen.
8. Proben Sie das Failover einmal, bevor Sie es wirklich brauchen.

GitHub hat über Jahrzehnte Goodwill aufgebaut, und ein paar Ausfälle ändern daran nichts. Bleiben Sie dankbar, bleiben Sie gespiegelt — und bleiben Sie überwacht.

Bereit für den nächsten Ausfall? Erstellen Sie Ihr kostenloses isthisthing.online-Konto und machen Sie aus dem nächsten GitHub-Hickser eine fünfminütige Pause statt eines verlorenen Nachmittags.