Störung bei Issues und Webhooks – behoben

 (githubstatus.com)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • GitHub untersuchte eine Leistungsbeeinträchtigung bei Issues und Webhooks und setzte den Vorfall am 4. Mai 2026 um 16:40 UTC auf den Status „behoben“
  • Von diesem Vorfall betroffen waren Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages und Codespaces
  • Um 15:45 UTC begann die Untersuchung einer Leistungsbeeinträchtigung bei Issues und Webhooks; um 15:48 UTC wurde sie auf die Untersuchung von erhöhter Latenz und Timeouts in mehreren GitHub-Diensten ausgeweitet
  • Ab 16:25 UTC wurden Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces und Webhooks nach und nach normalisiert oder entlastet
  • GitHub erklärte, dass sich die Latenzzeiten dienstweit normalisiert hätten, und arbeite weiter an der Verhinderung eines erneuten Auftretens sowie an der Root-Cause-Analyse, die veröffentlicht werde, sobald sie bereit sei

Überblick über die Störung

  • GitHub teilte nach der Untersuchung gemeldeter Leistungsbeeinträchtigungen bei Issues und Webhooks mit, dass die Störung behoben wurde
  • Die Störung betraf Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages und Codespaces
  • GitHub dankte den Nutzern für ihre Geduld während der Bearbeitung des Problems und erklärte, eine detaillierte Root-Cause-Analyse zu veröffentlichen, sobald sie bereit sei

Verlauf

  • Beginn der Untersuchung

    • Am 4. Mai 2026 um 15:45 UTC wurde mitgeteilt, dass gemeldete Leistungsbeeinträchtigungen bei Issues und Webhooks untersucht werden
    • Um 15:48 UTC wurde die Meldung erweitert: Untersucht würden nun erhöhte Latenz und Timeouts in mehreren GitHub-Diensten

  • Ausweitung auf weitere betroffene Dienste

    • Um 15:48 UTC wurde mitgeteilt, dass Git Operations von einer Leistungsbeeinträchtigung betroffen sei
    • Um 15:50 UTC wurde mitgeteilt, dass Packages von einer Leistungsbeeinträchtigung betroffen sei
    • Um 15:51 UTC wurde mitgeteilt, dass Actions von einer Leistungsbeeinträchtigung betroffen sei
    • Um 15:51 UTC wurde mitgeteilt, dass Pull Requests von einer eingeschränkten Verfügbarkeit betroffen seien
    • Um 15:56 UTC wurde mitgeteilt, dass Pull Requests von einer Leistungsbeeinträchtigung betroffen seien
    • Um 16:05 UTC wurde mitgeteilt, dass Codespaces von einer Leistungsbeeinträchtigung betroffen sei
    • Um 16:06 UTC wurde mitgeteilt, dass Pages von einer Leistungsbeeinträchtigung betroffen sei

  • Normalisierung und Entlastung

    • Um 16:25 UTC wurde mitgeteilt, dass Git Operations wieder normal funktionieren
    • Um 16:28 UTC wurde mitgeteilt, dass Actions und Packages wieder normal funktionieren
    • Um 16:29 UTC wurde mitgeteilt, dass Pages wieder normal funktionieren
    • Um 16:29 UTC wurde mitgeteilt, dass sich die Latenzzeiten dienstweit normalisiert haben und die Untersuchung der Ursache sowie Maßnahmen zur Verhinderung eines erneuten Auftretens weiterlaufen
    • Um 16:32 UTC wurde mitgeteilt, dass Pull Requests wieder normal funktionieren
    • Um 16:34 UTC wurde mitgeteilt, dass die Leistungsbeeinträchtigung mit Auswirkungen auf Issues entlastet wurde und zur Bestätigung der Stabilität weiter überwacht wird
    • Um 16:35 UTC wurde mitgeteilt, dass die Leistungsbeeinträchtigung mit Auswirkungen auf Codespaces entlastet wurde und zur Bestätigung der Stabilität weiter überwacht wird
    • Um 16:35 UTC wurde mitgeteilt, dass Webhooks wieder normal funktionieren

  • Behoben

    • Um 16:36 UTC wurde mitgeteilt, dass die Leistungsbeeinträchtigung entlastet wurde und zur Bestätigung der Stabilität weiter überwacht wird
    • Um 16:40 UTC wurde der Vorfall auf den Status behoben gesetzt
    • Die detaillierte Root-Cause-Analyse soll veröffentlicht werden, sobald sie verfügbar ist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • GitHub hat überraschende Nutzungszahlen veröffentlicht und den Anstieg auf agentisches Coding zurückgeführt; irgendwann werden sie wohl die Rate Limits ändern, die Nutzung im kostenlosen Tarif reduzieren oder einen anderen Weg finden müssen, die Last zu senken.
    Es wirkt ziemlich offensichtlich, dass die Infrastruktur mit diesem Wachstum nicht Schritt hält, und es ist unwahrscheinlich, dass GitHub die gestiegenen Kosten einfach dauerhaft selbst trägt. Ich bin gespannt, wie sich GitHub weiterentwickelt.

    • Am 3. April sagte die GitHub-COO bereits, dass die Aktivität auf der Plattform stark ansteigt.
      2025 gab es 1 Milliarde Commits, jetzt sind es 275 Millionen pro Woche, was selbst bei nur linearem Wachstum einem Tempo von 14 Milliarden in diesem Jahr entspricht. GitHub Actions ist ebenfalls von 500 Millionen Minuten pro Woche im Jahr 2023 auf 1 Milliarde Minuten pro Woche im Jahr 2025 gestiegen und hat diese Woche bereits 2,1 Milliarden Minuten erreicht.
      Angeblich wird massiv auf zusätzliche CPU-Kapazität, den Ausbau von Diensten und die Stärkung der GitHub-Kernfunktionen gedrängt.
      https://x.com/kdaigle/status/2040164759836778878
      Dazu gibt es auch einen aktuellen Blogpost zur Verfügbarkeit: https://github.blog/news-insights/company-news/an-update-on-...
      Die Skalierungsprobleme, mit denen GitHub-Ingenieure zu kämpfen haben, sehen wirklich nicht trivial aus.
    • Über Jahrzehnte der Beobachtung hinweg gab es Systeme, die jede einzelne Aufgabe billig machen, und Systeme, die aggressiv horizontal skalieren; oft haben Erstere Letztere deutlich geschlagen.
      GitHub scheint zum Beispiel die /pulls-Seite eines Repositories wie eine Suchanfrage implementiert zu haben; das vorab ausgefüllte Suchfeld war ein Hinweis darauf, und beim Ausfall des Search-Backends letzte Woche wurden Pull Requests nicht geladen, womit es fast bestätigt war. Man hätte es aber auch mit einem normalen API-Aufruf implementieren können, der nur offene Pull Requests lädt; diese API existiert und ist nicht ausgefallen.
      Wenn GitHub die oberen 95-%-Vorgänge wie Seitenladevorgänge und die dazugehörigen API-Calls identifizieren und optimieren würde, könnte allein die Vereinfachung die Backend-Last wohl um mehr als das Fünffache senken.
      Auch beim Diff-Viewer scheint es viel Verbesserungspotenzial zu geben. Ein großer Teil der schrecklichen Ineffizienz liegt vermutlich im Frontend, das das Backend nicht direkt belastet, aber normale git-Kommandozeilenfunktionen sind sehr schnell.
    • Es wirkt, als kämen wir jetzt an einen Punkt ohne Rückkehr. Wenn kostenlose und bezahlte Infrastruktur nicht getrennt werden, weiß ich nicht, ob sie sich allein durch horizontale Skalierung aus dem selbst gegrabenen Loch befreien können.
      So wie ein neues Produkt zehnmal besser sein muss, damit jemand wechselt, bekommt ein Konkurrent auch dann gratis einen Zehnfach-Vorteil, wenn das bestehende Produkt zehnmal schlechter wird.
    • Nachdem GitHub das vor einer Woche im Blog gepostet hatte und GitHub-Führungskräfte es einen Tag später in HN-Kommentaren wiederholten, wurde es blitzschnell zum Allgemeinplatz, dass der Zuverlässigkeitsverfall seit 2019 nicht an der Microsoft-Integration von 2019 liegt, sondern an etwas, das erst 2023 aufgetaucht ist.
      PR wirkt. Am Ende lautet die Schlussfolgerung, dass GitHub ausfällt, weil es zu erfolgreich ist.
    • Ich bin sehr dafür, die gesamte LinkedIn-Serverkapazität zu GitHub umzuschichten.

  • Laut https://mrshu.github.io/github-statuses liegt die Uptime von GitHub in den letzten 90 Tagen bei 84,92 %.
    Ich verstehe nicht, wie das auch nur ansatzweise akzeptabel sein soll.

    • Die Seite scheint Ausfallzeiten überzuzählen. Wenn man nur die major- und critical-Ausfälle filtert, die es auf die HN-Startseite schaffen, ist es immer noch schlecht, aber nicht so schlecht wie 84,92 %.
      https://isgithubcooked.com/?severities=major.critical
    • Ist es nicht. Heutzutage passieren viele inakzeptable Dinge, und trotzdem wirkt es, als würden alle sie einfach hinnehmen.
    • Nicht einmal two eights, geschweige denn three nines.

  • Die Performance hat inzwischen ein schwer akzeptables Niveau erreicht. Es vergeht keine Woche mehr, in der GitHub die Arbeit nicht unterbricht.

    • KI-Agenten haben die Skalierungseigenschaften des gesamten Internets faktisch verändert.
      Früher konnte GitHub davon ausgehen, dass eine begrenzte Zahl von Menschen die Plattform auf menschliche Weise und mit beobachtbaren Mustern nutzt, und hat vermutlich passend zu diesen Mustern skaliert und UI/UX-Flaschenhälse optimiert.
      Jetzt hat aber jeder einen oder mehrere Bots, die rund um die Uhr laufen, und das überlastet viele Dienste. Besonders solche, die inzwischen agentenzentriert sind wie das heutige GitHub.
    • Seit Monaten war das schon nicht mehr akzeptabel, und jetzt sind wir fast an dem Punkt, an dem man aktiv nach Alternativen suchen sollte.
    • Man sollte sich schon freuen, wenn nicht mal eine Woche, sondern nur ein Tag ohne Ausfall vergeht.
      Ich weiß schon gar nicht mehr, der wievielte Montagmorgen nach pazifischer Zeit das jetzt in Folge ist.
    • In Europa ist es deutlich besser. Ich hatte meine Arbeit schon einige Stunden vor Beginn dieses Ausfalls beendet, und ich kann mich in den letzten Monaten kaum an größere Ausfälle erinnern, die die Arbeit wirklich gestoppt hätten.
      Einmal wurde ich abends bei einem Hobbyprojekt davon betroffen.
    • Das akzeptable Niveau liegt aus meiner Sicht schon lange hinter uns.

  • Inzwischen konkurrieren GitHub ist down-Posts auf der HN-Startseite jede Woche mit dem neuesten LLM-Hypepost.
    Ich überlege, alle privaten Projekte zu Codeberg umzuziehen. Nicht nur wegen der GitHub-Stabilität, sondern auch weil mir eine Alternative gefällt, die nicht fest an einen Big-Tech-Konzern gebunden ist.

    • Der schlimmste Spam war dieses „Claude Code ist fast Magie“, aber gerade scheint er vorübergehend von GitHub-Statusposts verdrängt worden zu sein. Vielleicht ist gerade einfach eine ruhige Phase für Claude-Werbung.
    • Und trotzdem bist du noch nicht umgezogen; genau das ist das Problem dominanter Plattformen. Ein bisschen Unbequemlichkeit und Trägheit reicht schon aus, damit niemand geht.
      Auch ganz ohne monopolistischen Missbrauch, und hier ist Microsoft gemeint.

  • Komischerweise scheint fast alles außer Copilot im degradieren Zustand zu sein. Die Witze schreiben sich von selbst.

    • Verglichen mit den Funktionen, die gerade beeinträchtigt sind, ist die gesamte Funktionalität von Copilot nur von begrenztem Nutzen.
    • Copilot ist von GitHubs Code-Hosting-Seite vermutlich vollständig getrennt und läuft auf ganz anderer Infrastruktur, ohne starke Abhängigkeit vom Rails-Monolithen.

  • Es ist merkwürdig und etwas traurig, dass ich offenbar beginne, einen sechsten Sinn für GitHub-Ausfälle zu entwickeln.
    Vor etwa einer Stunde habe ich in einem Pull Request auf „Resolve Conversation“ geklickt, und es schlug ein paarmal fehl; die Fehlermeldung erschien außerhalb des sichtbaren Bereichs weiter unten auf der Seite, sodass ich sie zuerst gar nicht sah. Bei mehreren Aktionen musste ich die Seite neu laden, damit der Server den neuen Zustand übernahm.
    Ich sagte einem Kollegen, GitHub habe vermutlich in einem anderen Dienst Probleme, die auf PR-Kommentare übergeschwappt seien, und das könne sich noch zu einem größeren Ausfall auswachsen.

    • Ich habe gerade bei PR-Review-Kommentaren dasselbe Signal gesehen. Ich habe die Statusseite geprüft, sie war grün, und ich dachte mir, das würde nicht lange so bleiben — und genau so war es.

  • Der kostenlose Tarif muss beschnitten werden.
    Ich habe in den letzten 2,5 Monaten 4.000 Commits gemacht, und zwar nur auf main. Außerdem lade ich täglich eine Menge Artefakte für Regressionstests hoch.
    Die Kosten: 0 Dollar.

    • Ehrlich gesagt hasse ich die kostenlosen Tarife solcher SaaS-Produkte.
      Früher habe ich kurz den nutzungsbasierten Git-Dienst von Google auf GCP verwendet, als es ihn gab. Ich wollte etwas besitzen, das mir gehört. Aber alle nutzten das „kostenlose“ GitHub, und wie viele andere Google-Dienste wurde auch dieser Dienst offenbar eingestellt.
      Also nutze ich jetzt GitHub kostenlos, aber eigentlich würde ich lieber einem großen Cloud-Anbieter für Repository- und Nutzungskosten Geld zahlen.
    • Wenn man das macht, würden die Open-Source-Projekte, die noch nicht gegangen sind, abwandern.
    • Nur bezogen auf die Repository-Seite sind das eher rund 2 Minuten CPU-Nutzung.
    • GitHub sollte eine Schrottcode-Steuer einführen. Mit Claude gemeinsam geschrieben? Zahlen. Zu viele Gedankenstriche in Kommentaren? Zahlen. In kurzer Zeit sehr viel Code geschrieben? Zahlen.

  • Das wird wirklich absurd. Die Statusseite wird gelegentlich ignoriert, weil auch Copilot als „beeinträchtigt“ markiert ist, aber man sollte sehen, dass die Verfügbarkeit von Pull Requests bei 95,5 % liegt und damit sogar unter Copilot mit 96,4 %.
    Wie soll ich ein „LGTM“ kommentieren, wenn ich nicht einmal auf den PR zugreifen kann?

  • Immerhin lernen die Leute jetzt, wie man den Befehl git remote benutzt.