Aktuell liegt eine Störung bei GitHub vor

 (githubstatus.com)
1 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bei Pull Requests kommt es zu Leistungseinbußen, und auf den Seiten /pulls und /repo/pulls werden möglicherweise nicht alle indizierten Pull Requests angezeigt
  • Derzeit befinden sich nicht alle indizierten Dokumente im Elasticsearch-Cluster, aber die Pull-Request-Daten selbst sind nicht verloren gegangen und werden bei Aktualisierungen erneut indiziert
  • Parallel laufen Arbeiten zur Neuindizierung der verbliebenen Indizes sowie zur Beschleunigung eines vollständigen Reindex für die Wiederherstellung der vollständigen Ergebnisse, wobei Genauigkeit und die Vermeidung zusätzlicher Auswirkungen Priorität haben
  • In der Komponenten-Statusübersicht ist nur Pull Requests als beeinträchtigt markiert; Git Operations, Webhooks, API Requests, Issues, Actions, Packages, Pages, Copilot, Codespaces und Copilot AI Model Providers stehen auf Operational
  • In der jüngeren Historie werden außerdem mehrere Störungsfälle und Wiederherstellungsmaßnahmen offengelegt, darunter Suchverschlechterungen, fehlgeschlagene Actions-Jobs, fehlgeschlagene Starts von Copilot-Agent-Sitzungen, Regressionen in der Merge Queue, Verzögerungen bei Projects und fehlgeschlagene Codespaces-Verbindungen

Aktueller Störungsstatus

  • Bei Pull Requests kommt es zu Leistungseinbußen; dies ist unter Incomplete pull request results in repositories veröffentlicht
  • Auf den Seiten /pulls und /repo/pulls werden möglicherweise nicht alle indizierten Pull Requests angezeigt
    • Im Elasticsearch-Cluster befinden sich derzeit nicht alle indizierten Dokumente
    • Die Pull-Request-Daten selbst sind nicht verloren gegangen
    • Wenn ein Pull Request aktualisiert wird, wird er erneut indiziert
    • Zur Wiederherstellung der vollständigen Ergebnisse laufen außerdem beschleunigte Arbeiten an einem full reindex
  • Die verbleibenden Elasticsearch-Indizes werden derzeit neu indiziert, wobei Genauigkeit priorisiert und zusätzliche Auswirkungen vermieden werden sollen
    • Dabei wird weiterhin ein vorsichtiger Ansatz verfolgt, um Daten sicher backzufüllen

Komponentenstatus

  • In der aktuellen Statusübersicht ist nur Pull Requests als Degraded Performance markiert
  • Die übrigen wichtigen Komponenten befinden sich im Status Operational
    • Git Operations
    • Webhooks
    • API Requests
    • Issues
    • Actions
    • Packages
    • Pages
    • Copilot
    • Codespaces
    • Copilot AI Model Providers
  • Zusätzlich wird die Verfügbarkeit der letzten 90 Tage angezeigt
    • Pull Requests 99.58% uptime
    • API Requests 99.95% uptime
    • Packages 99.97% uptime
    • Copilot AI Model Providers 100.0% uptime

Regionale Statusseiten und Abonnementpfade

Jüngere Störungshistorie

  • 28. Apr.: Teilweise Störung bei einigen GitHub-Diensten

    • Der Eintrag Disruption with some GitHub services ist behoben
    • Bei Actions-hosted-Ubuntu-Jobs kam es zu Startverzögerungen und Fehlschlägen
      • Einige Ausführungen von ubuntu-latest und ubuntu-24.04 waren verzögert oder schlugen fehl
      • Zeitweise waren etwa 5% der Jobs betroffen, später unter 2%, danach wieder unter 1%
    • Das Problem, das Actions-Ausführungen blockierte, wurde entschärft und der Normalbetrieb schließlich wiederhergestellt

  • 27. Apr.: GitHub-Suche beeinträchtigt

    • Der Eintrag GitHub search is degraded ist behoben
    • Durch Verbindungsprobleme mit Elasticsearch und zusätzliche Last kam es gleichzeitig zu Suchfehlern und Problemen in mehreren nachgelagerten Diensten
      • Betroffen waren Issues, Pull Requests, Packages und Actions
      • Es kam zu fehlgeschlagenen Workflow-Runs, fehlgeschlagenem Laden von Projects und Search-Timeouts
    • Nachdem die Ursache der zusätzlichen Last blockiert worden war, zeigten sich Anzeichen der Erholung; danach wurde auf Stabilisierungs-Monitoring umgestellt

  • 27. Apr.: Störung bei Copilot Cloud Agent Codex-Sitzungen

    • Der Eintrag Disruption with some GitHub services ist behoben
    • Im Copilot Cloud Agent kam es zu fehlgeschlagenen Starts von Codex-Agent-Sitzungen
      • Sie starteten über keinen Einstiegspunkt, einschließlich Issue-Zuweisungen und @copilot-Erwähnungen in Kommentaren
      • Betroffen waren 0.5% aller Copilot-Cloud-Agent-Aufgaben, rund 2,000 fehlgeschlagene Jobs
      • Andere Agent-Sitzungen von Copilot waren nicht betroffen
    • Ursache war ein model resolution mismatch bei Codex-Agent-Sitzungen, durch das zur Laufzeit ein inkompatibles Modell gewählt wurde
    • Als Gegenmaßnahme wurde ausgerollt, für Codex-Agent-Sitzungen ein stabiles Standardmodell auszuwählen

Wichtige Fälle mit veröffentlichter Root Cause

  • Regression in der Pull-Requests-Merge-Queue

    • Incident with Pull Requests ist behoben
    • Wenn in der Merge Queue das Squash-Merge-Verfahren verwendet wurde und die Merge Group mehr als einen PR enthielt, wurde ein falscher Merge-Commit erzeugt
      • Bei späteren Merges konnten dadurch Änderungen aus früheren PRs und früheren Commits zurückgesetzt werden
      • Im betroffenen Zeitraum waren 2,092 Pull Requests betroffen
    • PRs, die außerhalb der Merge Queue gemergt wurden, sowie einige Gruppen mit merge- oder rebase-Verfahren waren nicht betroffen
    • Ursache war, dass ein neuer Codepfad zur Berechnung der Merge Base mit unvollständigem feature flag gating ausgerollt wurde
    • Die Codeänderung wurde zurückgenommen und per erzwungenem Rollout in der gesamten Umgebung verteilt; Administratoren betroffener Repositories erhielten separat Wiederherstellungsanweisungen
    • Anschließend wird der Umfang der Tests zur Merge-Korrektheit erweitert, einschließlich Squash-Gruppen mit mehreren PRs

  • Claude- und Codex-Agenten konnten nicht über das Web gestartet werden

    • Disruption with users unable to start Claude and Codex agent task from the web ist behoben
    • Auf github.com konnten keine neuen Agent-Tasks mit Claude oder Codex gestartet werden
    • Ursache war eine Änderung im Routing-Code für Task-Erstellungsanfragen in Copilot mission control
    • Laufende Agent-Tasks und andere Copilot-Agent-Funktionen waren nicht betroffen
    • Die fehlerhafte Änderung wurde zurückgenommen; zusätzlich werden weiteres Monitoring und Integrationstests für den Task-Erstellungspfad eingeführt

  • Ausfall bei der Verarbeitung von Copilot-@Erwähnungen

    • Disruption with some GitHub services ist behoben
    • @copilot-Erwähnungen in Pull-Request-Kommentaren führten nicht zur Ausführung des Copilot coding agent
      • Von allen Pull-Request- und Issue-Kommentaren wurden etwa 23,000 Aufrufe, also 0.5% der Gesamtmenge, nicht verarbeitet
      • Das Erstellen, Anzeigen und Beantworten von Kommentaren selbst war nicht betroffen
    • Ursache war ein serialization error, der die Veröffentlichung von Events an einen Downstream-Consumer verhinderte
    • Nach dem Ausrollen eines Fixes zur Wiederherstellung der Event-Veröffentlichung lief die Verarbeitung wieder normal; außerdem werden das zugehörige Event-Schema überprüft und das Monitoring verbessert

  • Ausfall von Copilot Chat und Cloud Agent

    • Disruption with Copilot chat and Copilot Coding Agent ist behoben
    • Bei Copilot Chat und Copilot Cloud Agent auf github.com traten Fehler auf, wodurch sie in diesem Zeitraum nicht nutzbar waren
    • Auch Copilot Memory im Preview-Status war in Agent-Sitzungen nicht verfügbar
    • Ursache war ein durch eine Infrastruktur-Konfigurationsänderung ausgelöstes Problem mit Datenbankverbindungen
    • github.com wurde zuerst wiederhergestellt, die übrigen Regionen folgten schrittweise

  • Verzögerungen beim Projects-Dienst

    • Disruption with projects service ist behoben
    • Projects konnte nicht synchronisiert werden oder Änderungen wurden verzögert übernommen
      • Die Verzögerung bei der Übernahme von Änderungen wuchs auf bis zu etwa 45 Minuten an
    • Ursache war, dass ein serialization error Event-Fehlschläge und einen starken Anstieg von Resyncs verursachte und dadurch die Event-Verarbeitungsschicht überlastete
    • Durch Erhöhung der Verarbeitungsgeschwindigkeit eingehender Änderungen wurde das Problem entschärft; anschließend wurde das Backlog abgebaut und der Dienst wiederhergestellt

  • Beeinträchtigung von Code Scanning Default Setup und Code Quality

    • Partial degradation for code scanning default setup and for code quality ist behoben
    • Bei neuen Pull Requests wurden code scanning default setup und code quality analysis nicht ausgelöst
    • Zusätzlich trat ein Problem auf, bei dem neu erstellte Issues nicht im Project Board erschienen
    • Ursache war ein serialization error, durch den Code Scanning, Code-Quality-Analyse und Updates des Project Boards nicht korrekt ausgelöst wurden
    • Die Event-Veröffentlichung für code scanning und code quality wurde wiederhergestellt; die Seite mit dem Project Board wurde durch zusätzliche Codeänderungen und Reindex repariert
    • Für PRs, die vor oder während des Incidents nicht verarbeitet wurden, wird die Analyse erst durch einen neuen Push erneut ausgelöst

Weitere aktuelle Störungsfälle

  • Disruption with some GitHub services
    • Die Web-Erfahrung auf GitHub.com war beeinträchtigt, und etwa 1.5% der Web-Requests endeten mit Fehlern
    • Zeitweise waren rund 10% des Web-Traffics verlangsamt oder schlugen fehl
    • Ursache war eine Kapazitätsauslastung einer Cache-Komponente in einer Data-Center-Region
    • Der Traffic wurde in nicht betroffene Regionen umgeleitet und ein jüngstes Deployment zurückgerollt, wodurch der Dienst wiederhergestellt wurde
  • Incident with Codespaces
    • Verbindungen zu GitHub Codespaces über den VS Code editor schlugen fehl
    • Etwa 40% der Codespace-Starts scheiterten
    • SSH-Verbindungen waren nicht betroffen
    • Ursache war ein Ausfall eines vorgelagerten Download-Service, der den Download von VS Code Server blockierte, der zum Start benötigt wird
    • Als Gegenmaßnahme wurde ein Fallback eingeführt, der bei Beeinträchtigung des Standard-Endpunkts einen alternativen Downloadpfad nutzt
  • Disruption with some GitHub services
    • Beim Zugriff auf die Copilot Insights-Seite in GitHub Enterprise Cloud traten 500-Fehler auf
    • Betroffen waren rund 709 Nutzer, die gesamte Auswirkungsdauer betrug etwa 5 Stunden 10 Minuten
    • Ursache waren Authentifizierungsfehler in der Metrics-Pipeline und Änderungen an Tenant-Credentials
    • Es werden Diagnosewerkzeuge, feingranulareres Monitoring und stärkere Alerting-Mechanismen eingeführt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare

  • Noch problematischer ist, dass es jetzt stillschweigend fehlschlägt
    Zum Beispiel werden trotz dutzender PRs "There aren’t any open pull requests." angezeigt, was die Leute eindeutig in die Irre führt

    • Letzte Woche hat die Verwendung der Merge Queue versehentlich den Trunk zerschossen, und auch das ist stillschweigend fehlgeschlagen
    • Bei uns wurde schon darüber gewitzelt, dass es immerhin so aussieht, als hätten wir endlich alle PRs erledigt, und man uns dazu gratulieren könne
    • Selbst wenn die PR-Liste erscheint, werden teilweise nicht alle PRs der gerade betrachteten Kategorie angezeigt, was wirklich übel ist

  • Das trifft mich wirklich ziemlich hart
    Vor ein paar Monaten hat $PARENT_CONGLOMERATE aus Gründen von Synergie und Effizienz eine GitHub-Migration für alle untergeordneten Organisationen erzwungen, und jetzt ist $DAYJOB mit dem Wechsel von self-hosted GitLab an der Reihe
    Ich habe jetzt schon einige Beschwerden
    Die IT-Richtlinien rund um GH-Accounts sind widersprüchlich, sodass weder mein persönlicher Account noch ein früher extra für $DAYJOB angelegter Account genutzt werden kann und stattdessen ein neuer Account nach den IT-Vorgaben erstellt werden muss
    Wir nutzen kein Monorepo, sondern viele Groups, aber dieses Konzept hat in GitHub keine direkte Entsprechung, sodass wir die Projekt-Namespaces manuell aufräumen müssen
    Und jetzt sieht auch noch die Verfügbarkeit von GitHub so aus
    Die Release-Termine unseres Teams sind umsatzkritisch, sodass schon ein oder zwei Tage Verzögerung darüber entscheiden können, ob wir unsere Monatsziele erreichen
    In einer anderen Situation hätten wir umsatzkritischen Code vielleicht im Voraus gespiegelt, aber es scheint den Aufwand nicht wert zu sein, so eine guerillamäßige Umgehungslösung aufzubauen
    Schön wäre es, wenn man in einem Postmortem in naher Zukunft The Synergy Mandate verantwortlich machen könnte, aber ich weiß selbst, dass das realistisch nicht passieren wird
    Ich kann nur hoffen, dass wir die Umsatzziele weiter erreichen und das Produkt nicht wegen schwacher Zahlen gestrichen wird
    Während ich das schreibe, wird mir noch deutlicher, wie sehr sich diese Arbeit seit meinem Einstieg verändert hat

  • Ich möchte es allen OSS-Projekten noch einmal sagen
    Es ist mit einer einfachen CI-Aufgabe enorm leicht, Code zwischen mehreren Forges zu synchronisieren, und auch die E-Mail-Benachrichtigungen eines zweiten Forge verursachen kaum Zusatzaufwand
    Man sollte zumindest die Möglichkeit offenhalten, außerhalb von GitHub beizutragen, und am Ende ist das besser für das gesamte Ökosystem

    • Die Code-Synchronisierung selbst ist einfach und trivial, und die CI-Aufgabe löst genau genommen auch nur diesen Teil
      Für die meisten Projekte ist selbst das vielleicht nicht einmal zwingend nötig
      Schwierig ist alles rund um den Code
      Tickets und PRs, einschließlich geschlossener Einträge, als Historie
      Alle möglichen Links, die auf das Projekt verweisen
      CI-Konfiguration
      Bei großen Projekten auch die Struktur der Committer-Berechtigungen
      Falls nötig, müssen sogar alle Push-/Commit-/Branch-Regeln mit umgezogen werden
      Solche Dinge sind je nach Projekt extrem lästig zu migrieren, und manches geht dabei womöglich verloren
      Das noch größere Problem ist aber, dass man die grundlegende Plattform zum Auffinden von Software verliert
      Ich frage mich, wann endlich ein Fediverse für Software kommt
    • Die Synchronisierung ist nebensächlich, aber der eigentliche Kern ist CI
      GitHub Actions ist immer noch die beste Option, und weder die FSF noch andere OSS-Labs haben es geschafft, Open-Source-Maintainern eine wirklich brauchbare CI bereitzustellen
      Außerdem ist die CI-Last heute viel höher als früher
    • Eine eigene GitLab-Instanz zu betreiben, kann ebenfalls eine gute Lösung sein

  • Ich habe inzwischen wirklich das Gefühl, dass wir Alternativen ernsthaft vorantreiben müssen
    Das beginnt reale Auswirkungen auf unser Geschäft zu haben, und es gibt keinerlei Anzeichen dafür, dass es besser wird

    • Wenn man eine UI wie GitHub will, kann man Forgejo oder Gitea verwenden
      Dann muss man allerdings mit den Einschränkungen der org/repo-Struktur leben
      Wer ein ähnliches, aber leicht anderes Erlebnis will, ist bei GitLab richtig
      Wer etwas Kernel-näheres will, also Hosting und flexible Repository-Strukturen, SSH-Key-basierte Benutzerauthentifizierung und eine einfache Web-UI, kann gitolite mit cgit kombinieren oder gitweb verwenden
    • Wir hosten seit Jahren Gitea zusammen mit Drone/Woodpecker selbst, und es läuft ausgezeichnet
      Ob Gitea oder Forgejo, solange der gebotene Funktionsumfang passt, reicht das völlig aus
      Ich schaue gelegentlich in GitHub-Ausfall-Threads vorbei und lache, denn unsere Gitea-Instanz hatte in den letzten Jahren insgesamt nur wenige Minuten Ausfallzeit, und das waren alles geplante nächtliche Upgrades
    • Mich überrascht, dass GitLab nicht mehr Aufmerksamkeit bekommt
      Es ist keine vollständige Kopie, aber nahe genug dran; eher der Unterschied zwischen Apfel und Birne als zwischen Orangen und Äpfeln
    • Ich dachte dasselbe
      Allerdings ist GitHub wirklich eine klebrige Plattform: Wenn einmal Actions und alle möglichen Integrationen eingerichtet sind, kommt man nur schwer wieder weg
      Trotzdem ist es inzwischen schon fast absurd, wie häufig dort Ausfälle auftreten
    • Im Moment hoste ich Forgejo für Git und CI selbst, und es läuft zu meiner vollen Zufriedenheit

  • Es scheint nicht nur GitHub zu betreffen, sondern ein größerer Ausfall zu sein: https://downdetector.com

    • Der gemeinsame Nenner dürfte Azure sein

  • Wenn am Ende des Tages wieder ein y steht, heißt das wohl wie immer: GitHub-Ausfall

  • Auch Codeberg.org hat gerade Probleme

    https://status.codeberg.org/status/codeberg

    https://social.anoxinon.de/@codebergstatus/11647770704799298...

  • Wenn du es nicht magst, dass GitHub ausfällt, und auch nicht, dass KI deinen Code stiehlt, dann probier doch sourcehut
    Für mich passt es sehr gut, und ich würde mir wünschen, dass es als Plattform weiter wächst

    • Mir gefiel das Entdecken neuer Repositories so gut, dass ich komplett zu Codeberg gewechselt bin, und die meisten Projekte, die mich interessieren, sind ebenfalls dort
    • Ich verstehe nicht, was an sourcehut anders sein soll
      Am Ende ist es doch auch nur wieder ein weiterer zentralisierter Dienst, oder?

  • Diesmal dauert es ungewöhnlich lange
    Mir kommt der Witz in den Sinn, dass das Team, das es reparieren soll, wegen eines Claude-Session-Limits in der Cooldown-Phase festhängt und bis dahin nichts anfassen kann, während die einzige Person, die es noch ohne KI direkt beheben könnte, gerade wegen einer Operation abwesend ist
    Ich frage mich auch, was passiert, wenn die Generation, die noch ohne KI direkt repariert hat, komplett in Rente ist

  • Jedes Mal, wenn GitHub ausfällt, wechseln wieder ein paar Leute mehr zu ethischen Alternativen, und die Struktur, in der die FOSS-Community bei Microsoft einen SPOF hat, wird dadurch Stück für Stück schwächer

    https://sfconservancy.org/GiveUpGitHub/

    • Dem Anliegen stimme ich zu, aber der soziale Aspekt, dass so viele Projekte auf GitHub versammelt waren, hatte eindeutig auch Vorteile
      Zusammenarbeit war einfach, und inzwischen wird es aus vielen Gründen wieder friktionsreicher
      Issues werden auch immer häufiger als Spam missbraucht, und noch bösartigere Aktivitäten tauchen ebenfalls zunehmend auf
    • SPOF steht für Single Point of Failure