GitHub marked a disruption to Git operations, pull requests, issues, API requests and Actions resolved at 11:50 UTC on November 4, 2026. Its incident record described elevated errors and intermittent failures, with some requests failing or arriving late. GitHub had yet to explain the root cause in that record when checked for this article.
The public timeline spans two hours and one minute from the first investigation notice to resolution. That measures the reporting window, rather than establishing when every affected user first encountered trouble. For teams sorting through failed builds or interrupted reviews, the component updates give a more useful breakdown than the final resolution time alone.
Actions recovered after the other affected services
GitHub's first notice, at 09:49 UTC, named degraded performance for Git operations, issues and pull requests. Actions followed at 09:50. API requests were explicitly flagged at 11:11.
At 11:30 UTC, GitHub said the degradation affecting API requests, Git operations, issues and pull requests had been mitigated. Actions received its mitigation notice at 11:43 UTC, 13 minutes later. Both updates said GitHub was monitoring stability before it closed the incident at 11:50.
Those timestamps help narrow an investigation into a failed workflow. An Actions failure after 11:30 still falls within that service's reported recovery window. Timing alone cannot establish that the incident caused a particular job to fail, so check the job's logs before changing application code.
Retrying a job preserves its original commit
For failed runs that need another attempt, GitHub's workflow documentation describes how to rerun only the failed jobs. People with repository write permissions can do this from the Actions interface by selecting the run, opening Re-run jobs, then choosing Re-run failed jobs.
A rerun uses the original event's commit SHA and Git ref. It also uses the privileges of the person who originally triggered the workflow. If you've pushed a fix since the failure, rerunning that older job won't test the newer commit. Choose the run that matches the code you intend to verify.
GitHub's resolution notice promises a detailed root-cause analysis. That account should establish what failed and why several development services were affected. Until it appears, the published timeline supports recovery checks, but leaves the initiating fault unexplained.