GitHub recovers from brief platform-wide incident affecting Git, Actions and pull requests

What happened

GitHub suffered a brief, platform-wide service disruption on 7 October 2026 that simultaneously degraded several of its core subsystems: Git operations, pull requests, Actions, webhooks and Issues. According to GitHub's status page, the heavy impact was concentrated in a roughly ten-minute window between 15:06 and 15:16 UTC, and all systems had fully recovered by 15:58 UTC. The company is still investigating what caused the disruption.

The incident was noticed quickly outside GitHub as well: the status page itself reached the front page of Hacker News.

How the incident unfolded

GitHub first acknowledged the problem at 15:14 UTC, saying it was investigating reports of degraded availability affecting Actions, Git operations and pull requests. Within the next two minutes, webhooks and Issues were also flagged as degraded, bringing the number of affected components to five.

At 15:24 UTC, GitHub said it was seeing services recover and dated the platform-wide impact to the 15:06 to 15:16 UTC window. Mitigation then proceeded component by component over the following half hour: pull requests were marked mitigated at 15:31 UTC, Actions was reported as operating normally at 15:32 UTC, Issues at 15:47 UTC, and Git operations and webhooks at 15:49 UTC. At 15:56 UTC GitHub said the degradation had been mitigated, and at 15:58 UTC it confirmed full recovery across all systems while continuing to look into the root cause.

Recovery was uneven

The status history shows the recovery was not a straight line. Git operations were declared normal at 15:27 UTC, only to be listed as degraded again at 15:35 UTC. Webhooks followed a similar pattern, moving between degraded performance and degraded availability at 15:14 and 15:16 UTC, reported as degraded once more at 15:27 UTC, and only marked mitigated at 15:49 UTC. GitHub noted partial recovery across all systems at 15:41 UTC, while cautioning that it was still monitoring.

That kind of flapping is typical when mitigations are rolled out progressively across a large distributed system and monitoring signals lag behind real conditions, but it also indicates the initial remediation did not hold on the first attempt for every component.

Root cause still unknown

GitHub's most recent update, posted at 15:58 UTC, says only that the investigation into the root cause continues. The status page does not indicate whether the disruption originated in shared infrastructure, a configuration change or something else, and it remains to be seen whether the company will publish a fuller post-incident analysis.

Why it matters

GitHub sits at the centre of the software supply chain for a large share of the industry's development work. When Git operations, pull requests and Actions degrade at the same time, the effects compound: developers cannot reliably push, fetch or clone code, reviews and merges stall, and automated build, test and deployment pipelines hang or fail. Webhooks being degraded adds another layer, since many external systems, from chat notifications to deployment triggers, depend on them to react to repository events.

A ten-minute outage is survivable for most teams, but the breadth of this one is telling. Five distinct subsystems failing simultaneously points to a shared underlying cause rather than five coincidental bugs, and that is exactly the question GitHub's root-cause investigation now has to answer. The episode is also a reminder of how much of the world's version control, code review and CI infrastructure depends on a single provider, and how quickly a GitHub incident becomes everyone's incident.