Mehrere Ausfälle bei GitHub-Diensten

 (githubstatus.com)
2 Punkte von GN⁺ 5 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bei mehreren GitHub-Diensten, darunter Webhooks, Actions und Copilot, kam es gleichzeitig zu eingeschränkter Verfügbarkeit und Ausfällen
  • Zunächst wurde die eingeschränkte Verfügbarkeit von Copilot und Webhooks untersucht, später wurde der Untersuchungsumfang auf mehrere Dienstausfälle ausgeweitet
  • Actions war zusätzlich von einer separaten Leistungsverschlechterung betroffen; nachdem das zugrunde liegende Problem identifiziert war, wurden Gegenmaßnahmen eingeleitet
  • Nachdem die Beeinträchtigungen bei Actions und Copilot gemildert waren, wurden die Stabilität weiter überwacht und Verifizierungsarbeiten für die verbleibenden Dienste fortgesetzt; auch Webhooks wurde wieder in den Normalbetrieb versetzt
  • Der Vorfall wurde schließlich als vollständig behoben abgeschlossen; eine detaillierte Root Cause Analysis soll veröffentlicht werden, sobald sie bereit ist

Verlauf der Störung

  • Es kam zu Ausfällen mehrerer GitHub-Dienste, betroffen waren unter anderem Webhooks, Actions und Copilot
  • Zunächst wurde die eingeschränkte Verfügbarkeit von Copilot und Webhooks untersucht
  • Anschließend zeigten mehrere Dienste Nichtverfügbarkeit, woraufhin der Untersuchungsumfang ausgeweitet wurde
  • Actions litt zusätzlich unter einer Leistungsverschlechterung, während die Ursachenanalyse weiterlief
  • Nachdem das zugrunde liegende Problem bestätigt worden war, wurden Gegenmaßnahmen umgesetzt
  • Die Beeinträchtigungen von Actions und Copilot wurden gemildert, anschließend lief das Monitoring zur Sicherung der Stabilität weiter
  • Nach den Gegenmaßnahmen für viele Dienste wurden auch Verifizierungsarbeiten für die verbleibenden Dienste fortgesetzt
  • Webhooks wurde ebenfalls wieder in den Normalbetrieb versetzt
  • Abschließend wurde der Vorfall als vollständig behoben geschlossen; eine detaillierte Root Cause Analysis soll veröffentlicht werden, sobald sie bereit ist

Weiterführende Links

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 일 전
Hacker-News-Kommentare

  • Ich war gerade dabei, nach und nach verschiedene Dinge zu Hause per Self-Hosting umzuziehen, und habe gestern endlich meine Forgejo-Instanz daheim fertiggestellt.
    Mit Linux und Windows als VMs und macOS auf einem Mac Mini, inklusive CI/CD-Runner, liegen jetzt Quellcode, Actions und die tatsächliche Infrastruktur wirklich komplett bei mir zu Hause.
    Normalerweise dauert es nach einem Umzug auf Self-Hosting ein bis zwei Monate, bis sich Zufriedenheit einstellt, aber diesmal hatte ich schon am Tag nach der Migration das sichere Gefühl, dass diese Entscheidung richtig war, und das hat sich ziemlich gut angefühlt.

    • Die Idee eines Homelab reizt mich immer, aber sobald ich anfange, eines aufzubauen, bin ich schnell erschöpft.
      Wenn ich den ganzen Tag im Job kaputte Systeme repariere, möchte ich nicht auch noch nach Hause kommen und den persönlichen Sysadmin für mich selbst spielen.
      Ein ordentliches, leistungsstarkes Minisforum, das ich zu Weihnachten gekauft habe, steht auch auf meinem Schreibtisch, aber ich habe es noch nicht einmal eingeschaltet.
    • Sobald man mit Self-Hosting anfängt, merkt man sofort, wie langsam das moderne Web ist.
      Ich betreibe Forgejo zusammen mit mehreren anderen Diensten auf einem NUC und Proxmox, und Seiten laden in etwa 6 ms.
      Immich ist nicht ganz so schnell, aber immer noch deutlich schneller als Google Photos.
    • Ich betreibe schon eine Weile ein persönliches Forgejo und hoste dort alle privaten Side Projects.
      Die UI ist im Großen und Ganzen ähnlich, aber es ist viel angenehmer als GitHub. Dass die Uptime über 90 % liegt, reicht als Begründung eigentlich schon aus.
      In letzter Zeit erlebe ich GitHub-Probleme viel zu häufig, und selbst simples Herumbrowsen auf der Seite ist oft langsam oder bleibt gleich ganz hängen.
    • Ich bin vor Kurzem ebenfalls umgezogen, und am meisten überrascht hat mich, dass die Actions-Geschwindigkeit viel höher ist als bei GitHub.
      Linux und macOS habe ich mit einem Mac Mini und einer von Claude erzeugten Ansible-Task-Datei eingerichtet, aber die Konfiguration der Windows-VM sah ziemlich schmerzhaft aus.
      Ich würde gern wissen, ob du einen Weg gefunden hast, den Bereitstellungsprozess zu vereinfachen.
    • Gestern habe ich hier etwas über gitea gelesen, kurz nachgeschaut und bin dann sofort auf Self-Hosting umgestiegen und habe alle meine persönlichen Projekte zu Forgejo migriert.
      Öffentliche Projekte sind aber wegen des Arbeitsmarkts und der Netzwerkeffekte von GitHub schwer umzuziehen.
      Im Moment fühlt es sich an, als würde ich mit rund 20 lokalen Diensten Systemadministrator spielen, und das Wichtigste ist jetzt, dass die Verantwortung, Datenverlust zu verhindern, bei mir liegt, also brauche ich unbedingt regelmäßige Backups.

  • Wenn man https://mrshu.github.io/github-statuses/ ansieht, ist die Uptime auf 88,15 % gefallen.
    Selbst bei den einzelnen Komponenten liegt der Höchstwert nur bei 99,78 %, also gerade mal auf dem Niveau von two nines.

    • Die Größenordnung des Wachstums, die sie bewältigen müssen, ist absurd.
      2025 waren es noch 1 Milliarde Commits, jetzt sind es 275 Millionen Commits pro Woche, und selbst bei rein linearem Wachstum entspräche das dieses Jahr einem Tempo von 14 Milliarden Commits.
      GitHub Actions ist ebenfalls von 500 Millionen Minuten pro Woche im Jahr 2023 auf 1 Milliarde Minuten pro Woche im Jahr 2025 gestiegen, und diese Woche liegt der Wert bislang bei 2,1 Milliarden Minuten.
      Quelle ist ein Beitrag der GitHub-COO vom 2026-04-03: https://x.com/kdaigle/status/2040164759836778878
    • Ich frage mich, ob das damit korreliert, dass GitHub der Migration zu Azure Priorität einräumt.
      https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/
    • Die von Microsoft vorangetriebene AI ist für Self-Hoster und Linux-Fans also tatsächlich eine große Hilfe.

  • Ich frage mich, ob GitHub trotz dieser wiederholten Ausfälle tatsächlich nennenswerte Geschäftsverluste sieht.
    In der Branche hieß es lange, dass Zuverlässigkeit und Markenwert entscheidend seien, aber inzwischen wirkt es, als würde das kaum noch jemanden kümmern.
    Wenn meine Wahrnehmung falsch ist, lasse ich mich gern korrigieren.

    • Noch vor gerade einmal 2 bis 3 Jahren waren sich fast alle einig, dass für eine stabile und sichere Softwareauslieferung repeatable builds, eine verifizierte chain of custody und eine auditierbare bill of materials unverzichtbar sind.
      Aber sobald LLMs ein bisschen besser wurden, hatte ich das Gefühl, dass diese ganze Diskussion einfach verschwunden ist.
    • GitHub ist bereits eine so tief verankerte Plattform, dass selbst solche Ausfälle offenbar einfach als Kosten des Geschäfts betrachtet werden.
      Große Unternehmen sind durch interne Instanzen in gewissem Maß abgesichert, und der Rest ist entweder nicht so stark betroffen oder hat nicht die Ressourcen, eigene Lösungen zu bauen oder umzuziehen.
    • Von GitHub zu GitLab zu wechseln könnte sein, als käme man aus der Pfanne und geriete direkt ins Feuer.
      Es wäre gut, wenn es für Nutzer in größerem Maßstab wirklich brauchbare Alternativen gäbe.

  • Um auf Basis eines rollierenden 90-Tage-Zeitraums unter two nines zu fallen, bräuchte es wohl noch ungefähr 16 Stunden zusätzliche Ausfälle.

  • Man müsste wohl sagen, dass es keinen Grund zur Sorge gibt, denn die Statusseite behauptet weiterhin grün, 100 % betriebsbereit.
    Und das, obwohl man nicht einmal auf eine statische Seite zugreifen kann.

  • Inzwischen müsste jedes Mal ein HN-Post auftauchen, wenn es bei GitHub mal keinen Problemtag gibt.
    Oder das bedeutet einfach, dass der jetzige Zustand der Normalzustand ist.

  • Früher gab es bei Bitbucket einmal den Fall, dass über mehrere Repos hinweg ein kompletter Tag Git-History verloren ging.
    Das war weniger ein Ausfall als vielmehr ein Datenproblem dort; dank lokaler Klone ließ sich das meiste retten, aber Issues und PRs aus diesem Zeitraum waren einfach weg.
    Deshalb habe ich als Side Project angefangen, gitbacker zu bauen.
    Das Repo selbst zu sichern ist einfach, aber der wirklich interessante Teil ist das Backup der Metadaten.

  • Heute gab es schon wieder einen sehr schwerwiegenden Vorfall: https://www.githubstatus.com/incidents/zsg1lk7w13cf
    Wegen einer Regression bei der Nutzung von Merge Queue zusammen mit Squash Merge oder Rebase wurden laut GitHub zwischen 2026-04-23 16:05 und 20:43 UTC einige PRs falsch gemergt.
    Bei uns wurden in diesem Zeitraum auf dem Default-Branch etwa 8 Commits komplett rückgängig gemacht.
    So etwas Schwerwiegendes habe ich bei einem GitHub-Incident noch nie gesehen.

    • Downtime ist das eine Problem, aber Commits auf dem Default-Branch stillschweigend zurückzudrehen, ist ein Versagen auf einer ganz anderen Ebene.
    • Bei uns war es ähnlich.
      Ironischerweise hat ein Tool, das eigentlich Merge Conflicts verhindern soll, stattdessen direkt kaputte Commits in den Mainline-Branch geschrieben.
    • Bei uns sind auf main ebenfalls mehrere Commits verschwunden, während der PR-Status weiter auf merged stand.
      Das war extrem stressig.
    • Bei uns wurden in mehreren Repos ebenfalls PRs zurückgedreht.
      Downtime ist schon schlimm genug, aber PRs zurückzudrehen, ist noch einmal eine Stufe schwerwiegender.
    • Wir haben ebenfalls eine E-Mail mit einem angehängten PDF erhalten, in dem die betroffenen Commits und die Wiederherstellung beschrieben wurden.
      Das war wirklich ein komplettes Chaos.

  • Unsere Anforderungen sind mit Git-Repos + Actions relativ einfach, und die gelegentliche Downtime ist nicht völlig kritisch, weil wir kein Team sind, das ständig committet und deployt.
    Trotzdem suchen wir inzwischen ernsthaft nach Alternativen.
    Offenbar strömten gerade so viele Leute auf Alternativen, dass sogar SourceHut ausgefallen ist. Beim Schreiben dieses Beitrags war es down, jetzt ist es wieder erreichbar.
    https://sr.ht/

    • Vielleicht wäre tangled.org eine Option.

  • Allein heute gab es drei Incidents, jeweils fast über eine Stunde, aber der Tagesstatus ist komplett grün und zeigt keine erfasste Downtime.
    Sie unterscheiden sich auch nicht grundlegend von früheren Incidents mit roten Balken, außer dass sie offenbar nicht mehrere Stunden dauerten.
    Deshalb verstehe ich nicht, was diese grünen Balken überhaupt bedeuten sollen.
    Ich frage mich, ob sie erst später auf nicht grün umgestellt werden, wenn sich genug Leute beschweren, oder ob Vorfälle vom selben Tag nur kurz im Tooltip erscheinen und danach stillschweigend vergessen werden.
    Wenn man bedenkt, dass bei den bisherigen grünen Tagen im Tooltip gar keine Incidents auftauchen, heute aber mehrere, wirkt es so oder so wie eine absichtlich irreführende Darstellung.