142 GitHub incidents · März 2026 — official updates, affected components, duration and resolution details.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Dieser Vorfall wurde behoben. Vielen Dank für Ihre Geduld und Ihr Verständnis, als wir dieses Problem angegangen sind. Eine detaillierte Ursachenanalyse wird geteilt, sobald sie verfügbar ist.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Einige Benutzer können Fehler bei der Verwendung von Copilot Code Review auftreten. Wir haben die Ursache identifiziert und arbeiten an einer Minderung.
Wir wenden die Abschwächung an und erwarten eine Erholung innerhalb von etwa 30 Minuten.
Der Abbau wurde gemildert. Wir überwachen die Stabilität.
Dieser Vorfall wurde behoben. Vielen Dank für Ihre Geduld und Ihr Verständnis, als wir dieses Problem angegangen sind. Eine detaillierte Ursachenanalyse wird geteilt, sobald sie verfügbar ist.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über beeinträchtigte Leistung für Copilot AI Model Provider
Wir erleben eine eingeschränkte Verfügbarkeit für das Grok 4.6-Modell in Copilot Chat, VS Code und anderen Copilot-Produkten. Dies ist auf ein Problem mit einem Upstream-Modellanbieter zurückzuführen. Wir arbeiten mit ihnen zusammen, um das Problem zu lösen.
Auch das Modell Grok 4.5 hat die Verfügbarkeit beeinträchtigt. Wir arbeiten mit dem Upstream-Anbieter zusammen, um das Problem zu lösen.
Die Probleme mit unserem vorgelagerten Modellanbieter wurden behoben, und Grok-Modelle sind wieder in Copilot-Produkten und IDE-Oberflächen erhältlich. Wir werden weiterhin überwachen, um Stabilität zu gewährleisten, aber die Abschwächung ist abgeschlossen.
Dieser Vorfall wurde behoben. Vielen Dank für Ihre Geduld und Ihr Verständnis, als wir dieses Problem angegangen sind. Eine detaillierte Ursachenanalyse wird geteilt, sobald sie verfügbar ist.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über verminderte Leistung für Pull Requests
Diffs in der PR-Ansicht können für mehrere Minuten abgestanden sein. Wir untersuchen und skalieren Ressourcen.
Die Zeit zum Aktualisieren von Pull Request Diffs hat sich auf normale Schwellenwerte verbessert.
Dieser Vorfall wurde behoben. Vielen Dank für Ihre Geduld und Ihr Verständnis, als wir dieses Problem angegangen sind. Eine detaillierte Ursachenanalyse wird geteilt, sobald sie verfügbar ist.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über beeinträchtigte Leistung für Copilot AI Model Provider
Copilot erlebt eine höhere Fehlerrate bei OpenAI-Modellen, einschließlich gpt-5.2, gpt-5.3-Codex, gpt-5.4, gpt-5.4 und der gpt-5.6-Modellfamilie. Andere Modelle sind nicht betroffen.
Einer unserer Modelanbieter hat einen Vorfall am Ende bestätigt. Wir haben ihnen Details zur Verfügung gestellt, um das Problem zu identifizieren. Wir beginnen eine Erholung zu sehen.
Die Verschlechterung der Copilot AI Model Provider wurde gemildert. Wir überwachen die Stabilität.
Die Probleme mit unserem vorgelagerten Modellanbieter wurden behoben, und gpt-5.3-codex, gpt-5.4-mini, gpt-5.4-nano, gpt-5.5 und die gpt-5.6-Modellfamilie sind erneut in Copilot-Produkten und IDE-Oberflächen erhältlich. Wir werden weiterhin überwachen, um Stabilität zu gewährleisten, aber die Abschwächung ist abgeschlossen.
Zwischen 08:37 und 09:41 UTC am 31. August 2026 erlebte GitHub Copilot eine Verschlechterung, die mehrere GPT-Modelle betraf, darunter gpt-5.2, gpt-5.3-Codex, gpt-5.4, gpt-5.4-mini, gpt-5.4-nano und die gpt-5.6-Familie (Luna, Sol und Terra). Benutzer stießen auf erhöhte Fehlerraten und unterbrochene Streaming-Antworten. Andere Modelle waren nicht betroffen. Die Verschlechterung wurde durch ein Problem mit einem vorgelagerten Modellanbieter verursacht. GitHub-Ingenieure erkannten das Problem durch automatisierte Überwachung, zeigten Produktwarnungen für die betroffenen Modelle an und koordinierten sich mit dem Anbieter. Der Service wurde wieder normal, nachdem der Anbieter eine Minderung implementiert hatte.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über eine eingeschränkte Verfügbarkeit für Copilot AI Model Provider
Wir erleben eine eingeschränkte Verfügbarkeit des Kimi K3-Modells in Copilot-Produkten und IDE-Oberflächen. Dies ist auf ein Problem mit einem Upstream-Modellanbieter zurückzuführen. Während wir mit ihnen zusammenarbeiten, um das Problem zu beheben, empfehlen wir, ein anderes Modell auszuwählen oder "Auto" auszuwählen, um Copilot weiterhin zu verwenden.
Copilot AI Model Provider erleben eine verschlechterte Leistung. Wir untersuchen weiter.
Die Probleme mit unserem Upstream-Modellanbieter wurden gemildert und Kimi K3 ist wieder in Copilot-Produkten und IDE-Oberflächen erhältlich. Wir werden weiter beobachten, um Stabilität zu gewährleisten.
Am 27. August 2026, zwischen etwa 09:20 und 12:14 UTC, erlebte der Copilot-Service eine Verschlechterung des Kimi K3-Modells aufgrund eines Problems mit unserem Upstream-Anbieter. Benutzer stießen bei der Verwendung von Kimi K3 auf erhöhte Fehlerraten. Andere Modelle waren nicht betroffen. Das Problem wurde durch eine von unserem Anbieter eingeführte Minderung behoben. GitHub arbeitet mit unserem Provider zusammen, um die Widerstandsfähigkeit des Dienstes weiter zu verbessern, um ähnliche Vorfälle in Zukunft zu verhindern.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über verminderte Leistung für Aktionen und Pull Requests
Wir untersuchen erhöhte Verzögerungen und Timeouts, die sich auf Workflowläufe von Aktionen auswirken, die durch Pull Request-Ereignisse ausgelöst werden. 20% der Aktionen haben Starts von mehr als 5 Minuten verzögert und bis zu 4% der Läufe konnten nicht ausgelöst werden. Wir arbeiten aktiv an der Minderung und werden Updates bereitstellen, wenn wir mehr erfahren.
Wir haben Abschwächungen angewendet und sehen eine Wiederherstellung in Workflow-Läufen von Aktionen und blockierten Pull Request Mergers. Wir überwachen weiterhin die nachhaltige Gesundheit der Merge-Commit-Erstellung, bevor wir sie lösen.
Wir bestätigten die vollständige Genesung ab 23:58 UTC. Aktionen Workflow läuft und Pull Request Mergers funktionieren normal. Wir werden nun den Vorfall lösen, während wir weiterhin die Gesundheit des Dienstes überwachen.
Die Degradation von Aktionen und Pull Requests wurde gemindert. Wir überwachen die Stabilität.
Am 26. August 2026, von 21:55 UTC bis 23:58 UTC, verzögerten sich 2,6% der Workflow-Läufe, die durch Pull-Request-Ereignisse ausgelöst wurden, wobei die Auswirkungen auf ihrem Höhepunkt bis zu 25% anstiegen. Einige Benutzer erlebten auch Verzögerungen bei Pull Request Merge-Commit-Generierung, Mergeability-Informationen und Merge-Button-Verfügbarkeit. Aktionen und Pull Requests wurden bis 23:58 UTC vollständig wiederhergestellt; der Vorfall wurde um 00:26 UTC behoben, nachdem der normale Betrieb bestätigt wurde. Hintergrundjobs, die Pull Request Updates verarbeiten und Merge Commits generieren, wurden durch Timeouts beeinflusst, die eine einzelne Partition von Git-Daten erreichen. Dies führte zu einem Backlog in der Pull Request Merge-Commit Verarbeitung, Verzögerung Pull Request-Triggered GitHub Actions Workflows und einige Mergeability Informationen. Wir reduzierten die Arbeitsbelastung, verlagerten den Verkehr von der betroffenen Infrastruktur und stellten die betroffene Servicekomponente wieder in einen gesunden Zustand. Zusammen trugen diese Aktionen dazu bei, den Rückstand zu entleeren und den normalen Betrieb wiederherzustellen. Wir arbeiten daran, die Erkennung der Ressourcensättigung zu verbessern und die Auswirkungen der Kunden in diesem Szenario zu beseitigen, indem wir die Auswirkungen isolieren, Retries besser begrenzen und den Gegendruck stärken, um unsere Systeme unter Last widerstandsfähiger zu machen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Wir untersuchen derzeit vermehrte Fehler bei Abrechnungsdiensten. Kunden können fehlgeschlagene Seitenladungen von Abrechnungsbudgets beobachten, und Benutzer der Copilot-CLI können Fehler beim Starten oder Fortfahren von Sitzungen beobachten.
Wir haben eine Abschwächung angewendet, um die Nutzung des Copiloten zu entsperren, und haben eine Erholung für diese besondere Auswirkung beobachtet. Wir untersuchen und wenden weiterhin Abhilfemaßnahmen für die Störung der Rechnungsseite an, während wir überwachen, um sicherzustellen, dass Copilot wiederhergestellt bleibt.
Wir überwachen weiterhin die Abschwächung, die wir für die Unterbrechung der Rechnungsseite angewendet haben.
Unsere Abschwächung hält immer noch an, während wir weiter untersuchen, um die Ursache zu finden.
Unsere Abschwächung hält weiter an und die Servicebedingungen bleiben stabil. Wir untersuchen weiterhin die konzentrierte Arbeitsbelastung, die für das Problem verantwortlich ist, und bereiten zusätzliche vorbeugende Verbesserungen vor. Wir haben seit dem vorherigen Update keine wesentliche Änderung der Kundenauswirkungen festgestellt. Wir werden ein weiteres Update zur Verfügung stellen, wenn die Untersuchung fortschreitet.
Keine wesentlichen Änderungen seit dem vorherigen Update. Die Servicebedingungen bleiben nach der Minderung stabil, und wir haben keine weiteren Auswirkungen auf die Kunden beobachtet. Wir überwachen den Service aktiv und implementieren gezielte Korrekturen, um die zugrunde liegende Ursache zu beheben.
Am 26. August 2026, zwischen 20:40 UTC und 00:51 UTC am 27. August, erlebte GitHub Billing eine verschlechterte Leistung, die sich auf die Abrechnungsbudgetseiten und die GitHub Copilot CLI-Sitzungen auswirkte. Betroffene Kunden stießen beim Starten oder Fortfahren von CLI-Sitzungen auf fehlgeschlagene Budgetseiten oder Ausfälle. Wir haben diese Auswirkungen für eine kleine Anzahl von Kunden (<1%) bestätigt. Dies wurde durch eine konzentrierte Arbeitsbelastung verursacht, die Verarbeitungsverzögerungen in unserer Datenspeicherschicht verursachte. Automatisierte Retries erhöhten die Belastung und verlängerten die Degradation. Wir haben den Vorfall abgemildert, indem wir den Verkehr innerhalb unserer Infrastruktur neu ausbalanciert haben. Wir verbessern die Arbeitslastisolierung, das Wiederholungsverhalten und die Erkennung von konzentrierter Belastung, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern und unsere Zeit zur Erkennung und Minderung ähnlicher Vorfälle zu verkürzen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über eingeschränkte Verfügbarkeit für Aktionen
Pages erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Wir haben ein Problem mit einer primären Datenbank identifiziert und versagen sofort mit einer Replik
das primäre Failover hat die Leistung kurzzeitig verbessert, aber nicht vollständig gemindert, wir haben den eingehenden Verkehr gedrosselt und untersuchen Upstream-Probleme von Vitess
Wir glauben, dass wir das Problem identifiziert und behoben haben und den Traffic langsam wieder hochfahren, um sicherzustellen, dass er nicht wieder auftritt. Einige Kunden werden weiterhin Verzögerungen sehen, wenn wir hochfahren.
Pages funktioniert normal.
Wir beobachten weiterhin eine Erholung und verspätete Schlangen brennen ab. Einige Kunden werden weiterhin erhöhte Verzögerungen sehen, bis alle gedrosselten Arbeiten abgeschlossen sind - wir erwarten dies innerhalb der nächsten Stunde.
Wir beobachten weiterhin eine Erholung und erwarten, dass die Warteschlangen für eingehende Aktionen in <30min wieder normal sind. Die Arbeit wird weiterhin durch das System fließen, vorbehaltlich der Übereinstimmungsgrenzen pro Kunde.
Der Abbau, der die Aktionen beeinflusst, wurde gemildert. Wir überwachen die Stabilität.
Alle eingehenden Warteschlangen haben sich erholt und Actions funktioniert wie erwartet. 3,7% der Jobs, die größeren Läufern in der frühen Phase dieses Vorfalls zugewiesen wurden, warten auf die Läuferzuweisung. Diese werden innerhalb einer Stunde abgesagt. Andere Läufer bearbeiten erfolgreich alle neuen Jobs.
Am 26. August 2026 von 15:02 bis 15:45 UTC, Aktionen Jobs nicht starten. In den folgenden 2 Stunden bis 17:40 UTC wurden die Aktionen um mehr als 5 Minuten verzögert, da das System mit verzögerter Last aufholte. Diese Auswirkung wurde durch die Sättigung von Schreibvorgängen in die Datenbank ausgelöst, die von den Service-Verarbeitungs-Triggern für Aktionen-Workflows verwendet werden. Die primäre war fehlgeschlagen, aber das System erholte sich nicht vollständig. Die Sättigung wurde durch die wachsende tägliche Spitzenlast in Kombination mit einem Upstream-Problem in GitHubs Ereignisverarbeitungsinfrastruktur, https://www.githubstatus.com/incidents/hcbtzksccj2f, verursacht, das eine Burstverstärkung der bereits hohen Last verursachte. Downstream-Drossel, die später verwendet wurden, um sich zu erholen, wurden ~10% zu hoch eingestellt, um das System zu schützen. Um 15:45 UTC hat die Drosselung in Kombination mit Service-Neustarts den Kernzustand des Dienstes wiederhergestellt. Diese Drosseln wurden zwischen 15:54 und 17:22 Uhr allmählich angehoben, um die vollständige Webhook-Verarbeitung für Aktionen wiederherzustellen. Diese Rampe war absichtlich langsam, um sicherzustellen, dass wir das System nicht erneut überwältigen konnten, da unsere ursprüngliche Drosselung jetzt als falsch eingestellt bekannt war. Die Schlange der Webhook-Events wurde um 17:40 UTC vollständig abgebrannt. 3,7% der größeren Läuferjobs, zusammen mit einigen skalierbaren, selbst gehosteten Jobs, blieben in der Warteschlange oder warteten auf den Läufer. Wir setzten eine Änderung ein, um Jobs in diesem Zustand zu erzwingen, und sie wechselten um 18:40 Uhr UTC, etwa 50 Minuten nach der Vorfallsminderung, zum Scheitern. Die freigabe dieser jobs befreite auch gehostete konkurrenz für größere läuferjobs. Kunden, die Konkurrenzgruppen verwendeten, sahen längere Auswirkungen aufgrund eines separaten Problems, bei dem Läufer, die einer Teilmenge von Jobs zugewiesen waren, die vor dem Einsatz der Force-Revoke-Abschwächung getrennt waren, was den Fortschritt der Läuferakquisition verhinderte und Arbeitsplätze in einem Warte-für-Runner-Zustand verließ. Dies wurde am 27. August um 01:00 Uhr UTC gelöst. Einige Läufe, die während des 15:02-15:45 UTC-Incident-Fensters ausgelöst wurden, stießen auf einen Fehler, der sie auch nach der Servicewiederherstellung als Schlange stehen ließ. Im Backend waren diese Runs bereits fehlgeschlagen und werden 24 Stunden nach der Erstellung automatisch in den stornierten Zustand verschoben. Als Folgemaßnahme beheben wir die Ursache für diesen Warteschlangenzustand und verbessern unsere Fähigkeit, betroffene Läufe in großen Mengen zu stornieren. Mehrere Änderungen zur Verbesserung der allgemeinen Skalierbarkeit dieses Teils der Aktionen waren bereits abgeschlossen und wurden in der Produktion bereitgestellt. Die Einführung dieser Änderungen wird innerhalb der nächsten 24 Stunden abgeschlossen sein. Weitere Arbeiten zur Verbesserung der Skalierbarkeit, der Widerstandsfähigkeit und der anmutigeren Verschlechterung der Workflows von Actions sind im Gange. Wir nehmen auch einen Reparaturartikel, um das Löschen von hängengebliebenen oder wartenden Jobs in ähnlichen zukünftigen Fällen zu beschleunigen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Bitte beachten Sie die Zusammenfassung dieses Vorfalls: https://www.githubstatus.com/incidents/y1t7p9fzrlj2
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über verminderte Leistung für Aktionen
Fehler beim Warten und Ausführen von Aktionen-Jobs für eine Teilmenge von Kunden werden nun behoben. Wir beobachten die vollständige Erholung.
Der Abbau, der die Aktionen beeinflusst, wurde gemildert. Wir überwachen die Stabilität.
Am 24. August 2026, zwischen 13:33 UTC und 14:04 UTC, erlebten 3,8% der Aktionen Verzögerungen über 5 Minuten mit 1,25% der Aktionen läuft völlig fehlschlagen. Der Vorfall wurde durch einen Festplattenfehler auf einem Knoten verursacht, der eine von vielen Dienstinstanzen beherbergt, die für die Verarbeitung von Runner-Zuweisungsereignissen verantwortlich sind. Typischerweise werden Pods auf ungesunden Knoten automatisch ohne Auswirkungen entfernt und ersetzt. In diesem Fall, obwohl der Knoten stark degradiert war und nicht in der Lage war, Festplattenoperationen durchzuführen, sendete er weiterhin gesunde Signale und verhinderte, dass das System seine Arbeit sofort an einen anderen Ort verlagerte. Während dieses Zeitraums akkumulierten Ereignisse, die der betroffenen Komponente zugewiesen wurden, bis eine automatische Neuverteilung die Verarbeitung zu gesunden Komponenten um 13:54 UTC umleitete. Der Warteschlangenbestand wurde um 14:00 UTC gelöscht und die Verarbeitung wurde um 14:04 UTC wieder normalisiert. Um ein Wiederauftreten zu verhindern, verbessern wir die Erkennung und automatisierte Behebung von ungesunden Knoten, die nicht vollständig offline sind. Wir stärken auch die Resilienz auf Anwendungsebene, so dass blockierte Verbraucher automatisch schnell entfernt und ihre Arbeit neu zugewiesen werden, ohne auf die Wiederherstellung des betroffenen Knotens zu warten.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über eine eingeschränkte Verfügbarkeit für Copilot AI Model Provider
Wir erleben eine eingeschränkte Verfügbarkeit des Fable-Modells in Copilot-Produkten und IDE-Oberflächen. Dies liegt an einem Problem mit dem Upstream-Modellanbieter. Während wir mit ihnen zusammenarbeiten, um das Problem zu beheben, empfehlen wir, ein anderes Modell auszuwählen oder "Auto" auszuwählen, um Copilot weiterhin zu verwenden.
Am 24. August 2026, zwischen ca. 06:35 und 07:25 UTC, erlebte der Copilot-Service eine Verschlechterung des Claude Fable 5-Modells aufgrund eines Problems mit unserem Upstream-Anbieter. Benutzer stießen bei der Verwendung von Claude Fable 5 auf erhöhte Fehlerquoten, wobei Anfragen manchmal in der Mitte der Antwort fehlschlugen. Andere Modelle waren nicht betroffen. Das Problem wurde durch eine von unserem Anbieter eingeführte Minderung behoben. GitHub arbeitet mit unserem Provider zusammen, um die Widerstandsfähigkeit des Dienstes weiter zu verbessern, um ähnliche Vorfälle in Zukunft zu verhindern.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Am 21. August 2026, zwischen 14:00 und 14:07 UTC, dotcom Git-Operationen über SSH wurden abgebaut. Erfolgreich Git-Operationen über SSH fielen während des Peak-Impact-Fensters um mehr als 95%, wodurch Klonen, Abrufen oder Überdrücken von SSH für die meisten Benutzer für etwa vier Minuten effektiv nicht verfügbar waren. Git-Operationen über HTTPS waren nicht betroffen. Der Vorfall wurde durch einen Softwarefehler in unserer Load-Balancing-Infrastruktur verursacht, der durch eine Konfigurationsänderung ausgelöst wurde. Der Defekt trat nur auf, wenn Verbindungen mehrere Schichten von Load Balancern mit der neuen Konfiguration durchliefen, was bedeutete, dass er während der Kanarientests nicht erkannt wurde. Wir haben den Vorfall abgemildert, indem wir die Konfigurationsänderung zurückgefahren haben. Wir fügen Regressionsabdeckung für mehrschichtige Load-Balancer-Konfigurationen hinzu und verbessern die Überwachung und Alarmierung für Git-Operationen über SSH, um unsere Zeit für die Erkennung und Minderung ähnlicher Probleme in der Zukunft zu reduzieren.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Es kann zu Verzögerungen beim Starten von Aufgaben mit dem Copilot Cloud Agent kommen. Wir untersuchen das Problem aktiv und werden Updates bereitstellen, wenn wir mehr erfahren.
Wir haben die problematische Komponente identifiziert und arbeiten daran, zu einem gesunden Beispiel überzugehen. Weitere Updates werden bereitgestellt, wenn wir Abschwächungen durchführen.
Wir haben Probleme mit Copilot Cloud Agent-Aufgaben, was dazu führt, dass neu begonnene Aufgaben den laufenden Fortschritt nicht ordnungsgemäß anzeigen. Diese Copilot-Cloud-Agent-Aufgaben werden immer noch korrekt ausgeführt, es fehlt jedoch die richtige Transparenz. Wir untersuchen das Problem aktiv und werden Updates bereitstellen, wenn wir mehr erfahren.
Benutzer haben Verzögerungen beim Starten von Aufgaben mit Copilot Cloud Agent und können den Status dieser Aufgaben nicht sehen. Copilot Cloud Agent-Aufgaben werden noch abgeschlossen. Wir haben die Ursache des Problems identifiziert und setzen Abhilfemaßnahmen ein, um den Service wieder auf ein normales Niveau zu bringen. Wir werden in Kürze ein weiteres Update über die erwartete Erholungszeit bereitstellen.
Wir sehen Anzeichen für eine Wiederherstellung der Sichtbarkeit des Aufgabenstatus von Copilot Cloud Agent, aber diese Wiederherstellung ist langsamer als erwartet. Wir verfolgen zusätzliche mildernde Maßnahmen, um die Erholung zu beschleunigen.
Wir beobachten eine allmähliche Wiederherstellung der Sichtbarkeit des Aufgabenstatus des Copilot Cloud Agents, wobei sich die Sitzungsausgabe um etwa 1 Stunde verzögert. Wir haben zusätzliche Schritte unternommen, um die Erholung zu beschleunigen und werden die Auswirkungen weiterhin überwachen.
Wir beobachten weiterhin eine schrittweise Wiederherstellung der Sichtbarkeit des Aufgabenstatus von Copilot Cloud Agent, wobei sich die Sitzungsausgabe um etwa 1 Stunde verzögert. Wir haben zusätzliche Schritte unternommen, um die Erholung zu beschleunigen und werden die Auswirkungen weiterhin überwachen.
Wir beobachten weiterhin eine schrittweise Wiederherstellung der Sichtbarkeit des Aufgabenstatus von Copilot Cloud Agent, wobei sich die Sitzungsausgabe um etwa 1 Stunde verzögert. Wir haben zusätzliche Schritte unternommen, um die Erholung zu beschleunigen und erwarten, dass dies innerhalb der nächsten Stunde wirksam wird.
Wir beobachten weiterhin eine schrittweise Wiederherstellung der Sichtbarkeit des Aufgabenstatus von Copilot Cloud Agent. Die Ausgabe der Sitzung verzögert sich weiterhin um etwa 1 Stunde, da unsere Sanierungsschritte in Kraft treten.
Wir sehen eine allmähliche Wiederherstellung der Sichtbarkeit des Aufgabenstatus von Copilot Cloud Agent, da wir eine Lösung für die Ursache bereitstellen. Die Ausgabe der Sitzung bleibt um etwa eine Stunde verzögert, während die Sanierung fortgesetzt wird.
Zwischen 13:57 UTC am 20. August und 00:37 UTC am 21. August 2026 erlebten einige Benutzer des Copilot Cloud Agents Verzögerungen von bis zu 60 bis 90 Minuten, um den Status und die Ergebnisse ihrer Agentenaufgaben zu sehen. Die Agentenaufgaben selbst liefen während dieser Zeit weiter und wurden abgeschlossen; nur die Sichtbarkeit ihres Status wurde verzögert. Die Ursache war ein regionaler Ausfall in einem Cloud-Datenbankdienst eines Drittanbieters, den Copilot zum Speichern des Aufgabenstatus des Agenten verwendet. Wir sind über die betroffene Datenbank in einer gesunden Region gescheitert, haben Verarbeitungskapazität hinzugefügt, um den Backlog zu bearbeiten, und den normalen Betrieb wiederhergestellt, sobald der zugrunde liegende Dienst wiederhergestellt ist. Während des Vorfalls gingen keine Aufgabendaten verloren. Um zu verhindern, dass sich ähnliche Vorfälle wiederholen, entfernen wir die Datenbankkonfiguration, die uns anfällig für diesen regionalen Ausfall gemacht hat, und verbessern unsere Datenbank-Failover-Verfahren.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Wir untersuchen Berichte über das Versäumnis, Läufergruppen und läuferbezogene Berechtigungen für Kunden mit größeren Läufern zu laden.
Wir haben die Quelle eines Kommunikationsproblems zwischen den Aktionsdiensten identifiziert und arbeiten auf eine Minderung hin. Kunden können beim Laden von Runner-Gruppen und Runner-bezogene Berechtigungsprobleme beim Verwenden von Larger Runners auftreten.
Wir haben eine Abschwächung vorgenommen und sehen Erholungssignale. Wir werden die Wiederherstellung weiterhin überwachen und Updates bereitstellen.
Am 18. August 2026, zwischen 05:02 UTC und 11:30 UTC, konnten Kunden die Aktionen Runners und Runner Groups nicht über die GitHub-Benutzeroberfläche und -API anzeigen oder verwalten. Das Problem wurde durch Fehler in Backend-Anforderungen verursacht, die Runner- und Runnergruppendaten lesen. Die Fehler wurden durch ein abgelaufenes Authentifizierungszertifikat verursacht, das für diesen Dienst einzigartig ist. Das Zertifikat wurde in KeyVault gedreht, aber ein Schritt zur Aktivierung der Verwendung zur Laufzeit wurde angehalten, um das Wiederauftreten früherer Vorfälle zu verhindern, die durch diese Operation ausgelöst wurden. Die Auswirkungen wurden durch den Abschluss der Aktivierung des neuen Zertifikats im Backend-System gemindert. Wir haben zusätzliche Überwachung zu diesem und anderen Zertifikaten hinzugefügt. Dieser Service ist auch dabei, im Rahmen unserer Verfügbarkeits- und Skalierungsarbeiten ersetzt zu werden, wodurch dieser Authentifizierungspfad und die geheime Verwaltung mit Mustern für alle GitHub-Dienste in Einklang gebracht werden.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
Am 18. August 2026, zwischen 05:02 UTC und 11:30 UTC, konnten Kunden keine Jobs für größere Läufer ausführen und konnten die Läufer und Läufergruppen über die GitHub-Benutzeroberfläche und -API nicht anzeigen oder verwalten. Diese Probleme wurden durch Fehler in Backend-Anforderungen verursacht, die wichtige Metadaten zum Starten von Workflowläufen für größere Runner und zum Lesen von Runner- und Runner-Gruppendaten lösen. Die Fehler wurden durch ein abgelaufenes Authentifizierungszertifikat verursacht, das für diesen Dienst einzigartig ist. Das Zertifikat wurde in KeyVault gedreht, aber ein Schritt zur Aktivierung der Verwendung zur Laufzeit wurde angehalten, um das Wiederauftreten früherer Vorfälle zu verhindern, die durch diese Operation ausgelöst wurden. Wir haben die Probleme gemildert, indem wir die Aktivierung des neuen Zertifikats im Backend-System abgeschlossen haben. Wir haben zusätzliche Überwachung zu diesem und anderen Zertifikaten hinzugefügt. Der entsprechende Service ist auch dabei, im Rahmen unserer Verfügbarkeits- und Skalierungsarbeiten ersetzt zu werden, wodurch dieser Authentifizierungspfad und die geheime Verwaltung mit Mustern für alle GitHub-Dienste in Einklang gebracht werden.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
API Requests erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Aktionen erleben eine verschlechterte Leistung. Wir untersuchen weiter.
Wir sehen eine ungefähre Fehlerquote von 20% bei zahlreichen Erfahrungen, einschließlich Pull Requests, Issues und anderen. Untersuchungen sind derzeit im Gange und wir werden Updates veröffentlichen, sobald sie verfügbar sind
Pull Requests erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Wir erleben hohe Fehlerquoten von rund 20% für Web-Erlebnisse und Api-Traffic. Archiv-Downloads und Roh-Repository-Content-Downloads haben eine Fehlerquote von etwa 50%. Untersuchungen zur Ursache sind im Gange, und Updates werden weiterhin zur Verfügung gestellt werden, wie wir untersuchen.
Wir erleben hohe Fehlerquoten von rund 20% für Web-Erlebnisse und Api-Traffic. Archiv-Downloads und Roh-Repository-Content-Downloads haben eine Fehlerquote von etwa 50%. SAML und OIDC-Authentifizierung, SCIM und Team Sync sind ebenfalls betroffen. Die Untersuchungen laufen und wir werden weiterhin Updates bereitstellen, wenn wir weitere Informationen erfahren.
Copilot erlebt eine eingeschränkte Verfügbarkeit. Wir untersuchen weiter.
Probleme erleben eine eingeschränkte Verfügbarkeit. Wir untersuchen weiter.
Pull Requests erlebt eine eingeschränkte Verfügbarkeit. Wir untersuchen weiter.
Aktionen erleben eine eingeschränkte Verfügbarkeit. Wir untersuchen weiter.
Wir erleben hohe Fehlerquoten von rund 20% für Web-Erlebnisse und Api-Traffic. Archiv-Downloads und Roh-Repository-Content-Downloads haben eine Fehlerquote von etwa 50%. SAML und OIDC-Authentifizierung, SCIM und Team Sync sind ebenfalls betroffen. Wir führen derzeit Minderungsmaßnahmen auf der Grundlage unserer bisherigen Untersuchung durch und überwachen Verbesserungen.
Webhooks erlebt eine eingeschränkte Verfügbarkeit. Wir untersuchen weiter.
Pages erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Webhooks erlebt eine verschlechterte Leistung. Wir untersuchen weiter.
Wir erleben hohe Fehlerquoten von rund 20% für Web-Erlebnisse und Api-Traffic. Archiv-Downloads und Roh-Repository-Content-Downloads haben eine Fehlerquote von etwa 50%. SAML und OIDC-Authentifizierung, SCIM und Team Sync sind ebenfalls betroffen. Wir führen derzeit Minderungsmaßnahmen durch und werden Updates veröffentlichen, während wir Fortschritte machen.
Wir erleben hohe Fehlerquoten von rund 20% für Web-Erlebnisse und Api-Traffic. Archiv-Downloads und Roh-Repository-Content-Downloads haben eine Fehlerquote von etwa 50%. SAML und OIDC-Authentifizierung, SCIM und Team Sync sind ebenfalls betroffen. Wir arbeiten immer noch daran, die Ursache zu identifizieren und werden weiterhin Updates veröffentlichen, während wir mehr lernen und Abschwächung durchführen.
Wir haben die problematische Komponente identifiziert und Korrekturmaßnahmen ergriffen. Es gibt starke Anzeichen einer Wiederherstellung, aber wir arbeiten immer noch daran, den Service vollständig wiederherzustellen, wobei die Fehlerquoten immer noch leicht erhöht sind. Wir werden weitere Updates veröffentlichen, wenn die Wiederherstellung fortgesetzt wird.
Die Degradation von API Requests, Actions, Git Operations, Issues, Pages, Pull Requests und Webhooks wurde gemindert. Wir überwachen die Stabilität.
Git Operations erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Wir haben die problematische Komponente identifiziert und Korrekturmaßnahmen ergriffen, aber wir sehen verbleibende Auswirkungen auf zahlreiche Dienste. Wir werden weiterhin zusätzliche Minderungsmaßnahmen ergreifen und die verbleibenden Auswirkungen untersuchen.
Probleme erleben eine verschlechterte Leistung. Wir untersuchen weiter.
Wir haben die problematische Komponente identifiziert und Korrekturmaßnahmen ergriffen, aber wir sehen Restauswirkungen in Form von sporadischen Authentifizierungsfehlern. Wir werden weiterhin zusätzliche Minderungsmaßnahmen ergreifen und die verbleibenden Auswirkungen untersuchen.
Die Verschlechterung der Git-Operationen wurde gemildert. Wir überwachen die Stabilität.
API Requests erleben eine eingeschränkte Verfügbarkeit. Wir untersuchen weiter.
API Requests funktionieren normal.
Wir untersuchen weiterhin sporadische Authentifizierungsfehler. Wir haben Authentifizierungstoken-Retries teilweise deaktiviert und Verbesserungen festgestellt, und wir überwachen die Auswirkungen, bevor wir diese Minderung vollständig anwenden.
Wir untersuchen weiterhin sporadische Fehler, die die Copilot-Authentifizierung in einigen Anwendungen beeinflussen. Die Copilot-Nutzung über GitHub CLI und GitHub App bleibt unberührt.
Probleme funktionieren normal.
Wir werden weiterhin Minderungsmaßnahmen anwenden, um sporadische Copilot-Authentifizierungsfehler in einigen Anwendungen zu beheben. Wir erwarten eine vollständige Erholung innerhalb der nächsten 30 Minuten. Die Copilot-Nutzung über GitHub CLI und GitHub App bleibt unberührt.
Am 17. August 2026, von 13:28 bis 21:15 UTC (7h 47m), erlebte GitHub.com erhöhte Fehler und Latenz bei Issues, Pull Requests, APIs, Aktionen und Copilot. Zu Spitzenzeiten lagen die Web- / API-Fehlerraten bei etwa 20%, während Archiv- und Rohinhalts-Downloads etwa 50% erreichten. SAML/OIDC-Authentifizierung, SCIM und Team Sync waren ebenfalls betroffen, ebenso wie Aktionen-Workflows in GHEC mit Data Residency, die von öffentlichen Workflowschrittdefinitionen abhängen, die auf GitHub.com gehostet werden. Die meisten Dienste erholten sich um 16:36 UTC, als sich unser zentrales US-Rechenzentrum erholte; Aktionen wurden bis etwa 18:03 UTC abgebaut; und Copilot Token Service wurde bis 21:02 vollständig wiederhergestellt. Ein teil des ausfallenden verkehrs wurde von central us nach northern virginia verlegt, wo er erfolgreich bedient wurde, bis der netzwerkausfall in central usa behoben und behoben wurde. Verzögerte Antworten auf einen einzelnen internen Endpunkt lösten einen latenten Wiederholungsfehler im VS-Code aus, der den Datenverkehr um etwa das Zehnfache verstärkte und zu einer verzögerten Wiederherstellung für den Copilot-Tokendienst führte. Die unmittelbare Ursache des Fehlers war die Netzwerksättigung bei Load Balancern in den USA aufgrund eines neuen Verkehrsaufkommens. Ursprünglich wurde dies dadurch verursacht, dass ein Istio-Seitenwagen-Pod seine Parallelitätsgrenzen erreichte und aufgrund einer falsch konfigurierten Richtlinie, die den Host-Service, aber keine Seitenwagengrenzen beobachtete, nicht richtig skaliert wurde. Ein Fehler kaskadierte auf mehr und schließlich vier HAProxy-Knoten erschöpften ihre Flussgrenzen, verschlechterten den Gateway-Auth-Pfad und verursachten eine weit verbreitete Authentifizierungslatenz und -fehler. Das Problem wurde durch eine optimistische Retry-Logik verschlimmert, die interne Load Balancer überlastete. Das Pausing von HAProxy an diesen Knoten führte gleichzeitig zu einer sofortigen breiten Erholung. Der Retry-Sturm in Northern VA wurde durch 1 behoben, wodurch die Gateway-Retry-Logik mit einer PR und 2 vorübergehend reduziert wurde, um eingehende Copilot Token Service-Tokenanfragen bei den Load Balancern mit einer 403 zu blockieren und dann den Datenverkehr pro Site schrittweise wieder hochzufahren, damit Anrufer erfolgreich sein können. Residuale Copilot-Authentifizierungsfehler setzten sich fort, weil das Client-Wiederholverhalten das Laden verstärkte: Eine fehlgeschlagene Token-Operation konnte viele zusätzliche Anforderungen erzeugen und in eine Wiederholungsschleife eintreten. Der Datenverkehr des Copilot Token Service stieg von einem normalen 7-9K RPS auf 70-100K RPS. Die Reduzierung von Gateway-Authentifizierungs-Retries und das Blockieren von Retry-Triggering-Antworten stabilisierten den Copilot Token Service und schlossen die Wiederherstellung ab. Komplizierte Faktoren, die die Wiederherstellung behinderten, beinhalteten eine Reihe von Scraping-Angriffen auf Codeload-Endpunkte. Um eine Wiederholung zu verhindern, umfassen unsere Folgemaßnahmen: - Korrektur von Autoscaling-Richtlinien, um die Übereinstimmung und Kapazität des Service-Mesh-Sidecars zu berücksichtigen. Auditierung von Istio-Anforderung, Parallelität und Skalierungsgrenzen für betroffene Dienste. Überprüfung von Retry-Limits und Backoff-Verhalten über Gateways und Clients hinweg. Adressierung des VS-Code-Wiederholverhaltens, das den Copilot-Tokenverkehr verstärkt hat. Verbesserung der Load-Balancer-Kapazitätsüberwachung und der regionalen Failover-Sicherheitsmaßnahmen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über die beeinträchtigte Leistung einiger GitHub-Dienste.
GHEC Team Sync ist derzeit für Unternehmen mit persönlichen Konten degradiert, was zu Verzögerungen beim Synchronisieren von Teams mit IdP-Gruppen führt. Wir haben die Ursache der Verzögerungen identifiziert und arbeiten an einer Minderung. Wir werden um 20:00 Uhr UTC ein Update über unseren Fortschritt geben.
Wir haben eine Abschwächung vorgenommen. Zu diesem Zeitpunkt hat sich GHEC Team Sync für Unternehmen mit persönlichen Konten erholt. Teams, die mit IdP-Gruppen synchronisieren, sind in ihre normale Kadenz zurückgekehrt.
Am 13. August 2026, von 15:31:21 UTC bis 18:27:55 UTC, wurde die GitHub Enterprise Cloud-Teamsynchronisation für Unternehmen, die persönliche Konten verwenden, abgebaut. Organisationsteams erlebten Verzögerungen von bis zu 3 bis 13 Stunden (median 8 Stunden) bei der Synchronisierung mit IdP-Gruppen, was zu verzögerten Zugriffszuschüssen oder Entfernungen für Unternehmensbenutzer in 2,8% der Teams führte. Eine vorübergehende Änderung, die eingeführt wurde, um ein früheres Problem aufgrund der erhöhten Nutzung dieser Funktion zu beheben, blieb aktiv, nachdem sie entfernt werden sollte, was zu Synchronisationsverzögerungen in Zeiten mit hohem Volumen führte. Wir haben die temporäre Änderung entfernt und zusätzliche Ressourcen bereitgestellt, um das erhöhte Volumen zu bewältigen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über verminderte Leistung für Webhooks
Pull Requests erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Probleme erleben eine verschlechterte Leistung. Wir untersuchen weiter.
Git Operations erlebt eine verschlechterte Performance. Wir untersuchen weiter.
Pakete erleben eine verschlechterte Leistung. Wir untersuchen weiter.
Wir untersuchen derzeit eine kurze Verschlechterung des Dienstes für Git-Operationen (speziell Pushes), Probleme, Pull-Anfragen, Paketregistrierung und Webhooks zwischen 14:32 und 14:46 UTC. Wir haben die Quelle der Degradation identifiziert und untersuchen Minderungsstrategien, um ein Wiederauftreten zu verhindern.
Die Verschlechterung von Git-Operationen, Issues, Packages, Pull Requests und Webhooks wurde gemindert. Wir überwachen die Stabilität.
Wir haben vorübergehend einen Hintergrundjob deaktiviert, der die Auswirkungen verursacht hat. Zu diesem Zeitpunkt sind die Auswirkungen vollständig gemindert.
Zwischen 14:24 und 14:53 UTC am 13. August 2026 überwältigte ein routinemäßiger Hintergrundjob zum Löschen einer Organisation eine gemeinsame Schlüsseldatenbank, was dazu führte, dass mehrere GitHub-Dienste kurzzeitig erhöhte Fehler und langsamere Antworten zurückgaben. Am stärksten betroffen war die Webhook-Management-API mit geringeren Auswirkungen auf Git-Operationen, Pull-Anfragen, Probleme, Pakete, Anmelde- und Copilot. Die Auswirkungen wurden um etwa 14:53 UTC nach Beendigung des Auftrags von selbst behoben; wir haben den Vorfall um 15:36 UTC gelöst. Betroffene Benutzer haben möglicherweise eine kurze Zunahme von Fehlern und langsameren Reaktionen erlebt, vor allem beim Erstellen, Auflisten oder Aktualisieren von Webhooks, mit kleineren Auswirkungen auf das Abrufen von Anfragen, Problemen, Paketen und Git-Operationen. Die Ausfälle erreichten etwa 1% für mehrere Minuten um 14:37 UTC. Um zukünftige Vorfälle zu verhindern, haben wir bereits ein Update ausgeliefert, das den sichereren Löschpfad für Organisationen einschaltet, zusammen mit Obergrenzen für Löschvorgänge in Datenbanken. Aufbauend auf diesen Änderungen prüfen wir alle Massenlösch- und Bereinigungsaufträge, die in gemeinsam genutzte Datenbanken schreiben, um ähnliche Probleme in Zukunft zu vermeiden.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Berichte über beeinträchtigte Leistung für Copilot AI Model Provider
Wir erleben eine eingeschränkte Verfügbarkeit des Fable 5-Modells in Copilot-Produkten und IDE-Oberflächen. Dies ist auf ein Problem mit einem Upstream-Modellanbieter zurückzuführen. Während wir mit ihnen zusammenarbeiten, um das Problem zu beheben, empfehlen wir, ein anderes Modell auszuwählen oder "Auto" auszuwählen, um Copilot weiterhin zu verwenden.
Wir sehen eine bescheidene Erholung, aber immer noch eine eingeschränkte Verfügbarkeit für das Fable 5-Modell in Copilot-Produkten und IDE-Oberflächen. Dies ist auf ein Problem mit einem Upstream-Modellanbieter zurückzuführen. Während wir mit ihnen zusammenarbeiten, um das Problem zu beheben, empfehlen wir, ein anderes Modell auszuwählen oder "Auto" auszuwählen, um Copilot weiterhin zu verwenden.
Die Probleme mit unserem vorgelagerten Modellanbieter wurden behoben, und Fable 5 ist wieder in Copilot-Produkten und IDE-Oberflächen erhältlich. Wir werden weiterhin überwachen, um Stabilität zu gewährleisten, aber die Abschwächung ist abgeschlossen.
Am 13. August 2026, zwischen ca. 14:06 und 15:47 UTC, erlebte der Copilot-Service eine Verschlechterung des Claude Fable 5-Modells aufgrund eines Problems mit unserem Upstream-Anbieter. Benutzer stießen auf erhöhte Fehlerquoten, die bei 43% und durchschnittlich 12% lagen. Benutzer, die Auto oder alternative Modelle ausgewählt haben, waren nicht betroffen. Das Problem wurde durch eine von unserem Anbieter eingeführte Minderung behoben. GitHub arbeitet mit unserem Provider zusammen, um die Widerstandsfähigkeit des Dienstes weiter zu verbessern, um ähnliche Vorfälle in Zukunft zu verhindern.
Automatisch aus der offiziellen Störungsmeldung übersetzt.