GitHub Suffers Two-Hour Outage in Pull Requests, Git Operations, and Issues

GitHub registered an infrastructure failure this Wednesday morning (November 4, 2026) that simultaneously degraded five platform components: Git Operations, API Requests, Issues, Pull Requests, and Actions. GitHub's official status page marks the start of monitoring at 09:49 UTC (06:49 Brasília time) and resolution at 11:50 UTC (08:50 Brasília time), a window of just over two hours.

For those who depend on GitHub to work, this is not a footnote: it's the period during which git push, git clone, merging a Pull Request, opening an Issue, and running an Actions workflow could fail or be delayed without warning, in any repository, from any organization.

How the incident unfolded

GitHub publishes incremental status updates, and the history of this failure shows a picture that spread before being contained:

• 09:49 UTC (06:49 BRT): investigation begins, with degradation reported in Git Operations, Issues, and Pull Requests.
• 09:50 UTC (06:50 BRT): Actions joins the list, with degraded performance.
• 09:53 UTC (06:53 BRT): Pull Requests starts reporting degraded availability, not just performance.
• 10:38 UTC (07:38 BRT): GitHub confirms "elevated errors and intermittent failures" affecting PRs, Git Operations, and Issues, with no set timeline for mitigation.
• 11:11 UTC (08:11 BRT): API Requests also appears degraded.
• 11:17 UTC (08:17 BRT): team says it is "working on mitigation," with requests still possibly failing or being delayed.
• 11:30 UTC (08:30 BRT): first update that degradation in API Requests, Git Operations, Issues, and Pull Requests has been mitigated; monitoring period begins.
• 11:43 UTC (08:43 BRT): Actions is also marked as mitigated.
• 11:50 UTC (08:50 BRT): incident marked as resolved.

GitHub itself acknowledges, in closing the incident, that a root cause analysis (RCA) will be published separately, "once available," meaning the technical reason for the failure remained open at the time of resolution.

Why it affected so much at once

The list of affected components (Git Operations, API Requests, Issues, Pull Requests, and Actions) suggests a failure in a shared layer of GitHub's infrastructure, not an isolated service. When Git Operations degrades, push and clone fail at the root; when API Requests degrades as well, any integration that talks to GitHub's API (CI bots, review tools, internal dashboards) feels the impact in cascade, even without directly using the other components listed.

For those monitoring a pipeline, the most visible symptom was likely Actions: workflows triggered by a push or by opening a PR may have gotten stuck in queue, failed to clone the repository, or simply not triggered, because the originating event (push, Pull Request, Issue) was also degraded.

What remains unanswered

GitHub Status's report is operational, not technical: it records the what and the when, not the why. As of this incident's publication, there is no public indication of:

• Whether the problem originated from a configuration change, a deploy, or a hardware/network failure.
• Whether any data was actually lost or merely delayed (the text mentions requests that "may fail or be delayed," without detailing persistence).
• Whether the incident was related to a specific infrastructure region or was global.

In summary: GitHub confirms the impact and the mitigation, but leaves the root cause for a future post-mortem, a common practice among major cloud providers following multi-component incidents.

What this changes for everyday GitHub users

Two hours of intermittent degradation in Git Operations and Actions has a direct practical effect on teams that depend on continuous CI/CD: blocked deploys, PR merges stuck on a check that never ran, or a pipeline that fails due to a clone timeout rather than an actual error in the code. In these cases, it's worth checking status.githubstatus.com before diving into debugging a workflow that is actually healthy.

One practice that helps avoid making the incident worse: avoid aggressive, automatic retries of Actions jobs during a known degradation window, since this only adds load to infrastructure that is already under stress. Teams with critical deployments might also consider having a manual fallback path (local runner, repository mirror) so as not to be entirely dependent on GitHub.com's availability during windows like this.

The incident reinforces something every team that depends on a single hosted Git provider already knows in theory: Pull Requests, Issues, and Actions share infrastructure, and a problem in a base layer can take all three down at once, even if your repository's code hasn't changed at all.