GitHub Degrades Across Four Core Services on November 4

GitHub reported degraded performance across Git Operations, Issues, Pull Requests and Actions on November 4, 2026, as recorded on its status incident page. The company first said at 09:49 UTC that it was investigating reports of degraded performance for Git Operations, Issues and Pull Requests.

The scope widened within minutes. At 09:50 UTC, GitHub said Actions was experiencing degraded performance and that it was continuing to investigate. At 09:53 UTC it reported degraded availability for Pull Requests, again while the investigation was ongoing.

GitHub's status history attributes an elevated error rate peaking at 1.30% of all requests to the incident, with approximately 1.16 million failed requests in total. A separate status history entry for the Pull Requests service describes elevated latency and failures, with an average error rate of 0.15% and a peak of 0.28% of requests to that service. The two figures measure different scopes, one platform-wide and one limited to Pull Requests, and should not be compared directly.

The incident follows a related disruption earlier in the autumn. GitHub reported that on October 7, 2026, between 16:52 and 17:01 UTC, it experienced a recurrence of the write-operation outage from earlier that day, according to a status post.

The four affected services cover most of the points where a development workflow touches the platform. Git Operations handles clone, fetch and push traffic, the commands that copy code to and from GitHub. Issues carries planning and triage, the tracking of tasks and bugs. Pull Requests is where code review and merge decisions happen. Actions runs the continuous integration and delivery pipelines, the automated build, test and deployment jobs that often gate those merges. Degradation across all four at once differs from a fault confined to one feature. A failed pipeline, a blocked merge and a stalled push can each look like a problem in the code rather than in the platform hosting it.

In my view, the practical question for teams is less about the headline error percentage than about how their tooling responds when the platform degrades. Retry logic, queued deploys and pipelines that distinguish infrastructure failures from test failures tend to determine whether an incident like this costs an hour or an afternoon. Engineering organisations that depend heavily on hosted CI have a reason to review those behaviours, and the two GitHub incidents within a single month give them a concrete case to examine.