GitHub had two separate incidents on 5 October 2026, the longer one lasting 3h 42m and affecting Actions and Pages. Both were problems on GitHub's side, centred on delayed and failing workflow runs rather than anything in your own repositories or code.
Started
19:11 UTC
Duration
Lasted 3h 42m
Source
IsDown
Next time
GitHub is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Actions, GitHub Pages
What happened?
The first incident started at 19:11 UTC and ran for 3h 42m. GitHub initially described it as degraded performance for Actions, then narrowed it to delays assigning GitHub-hosted runners to jobs, which meant workflows took longer to start across multiple runner configurations. By 20:39 GitHub said this had turned into job failures as well as delays, and by 20:47 Actions availability itself was marked degraded. At 21:09 the scope widened again: some customers could not reach repository list, licensing and billing pages, and twelve minutes later GitHub Pages was also reported as degraded. Mitigations went in at 21:32, with GitHub saying queued jobs were clearing and new jobs were no longer delayed. Actions was reported back to normal at 21:54 and Pages at 22:40. The incident was marked resolved at 22:49 with GitHub saying a root cause analysis would follow, and none has been published as of that update. A second, separate incident started at 23:47 UTC, affecting access to organisation and enterprise billing and licensing pages, with a mitigation deployed by 00:05. That one was resolved at 01:32, a duration of 1h 46m, again with a promised root cause analysis still outstanding. No user reports were filed during either window on this page.
Learning
UptimeRobot's own probes against GitHub's api-auth and raw-cdn components, checked every 60 seconds from the EU and North America, stayed green through all of this, logging 100% uptime over 24 hours and 99.994% over 7 days. That is not a contradiction: the failure sat in the Actions job scheduler and runner assignment pipeline, plus some account pages, none of which those endpoints exercise. A CI pipeline can be stuck queuing jobs for hours while the parts of GitHub that serve raw files or handle authentication answer every request correctly. This is the common shape of a partial platform outage: the component you depend on for deployments breaks while the component your monitor happens to watch does not. If your deploys or builds stalled during either window, that was GitHub's runner and billing infrastructure, not your repository or your account configuration. Your own monitoring covers your half of the stack, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
