DEV TOOLS Signal 522
GitHub Actions suffers second-longest major outage in its history
↗
Illustration only Photo by Kier in Sight Archives on Unsplash
GitHub Actions suffered a prolonged outage that disrupted workflow execution and webhook delivery.
Continuous integration pipelines that rely on GitHub Actions may experience failed or delayed jobs, breaking automated testing and deployment. The outage also throttles webhook triggers, so code pushes and pull-request events may not start builds, forcing teams to add manual checks or alternative CI paths.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Runners were incorrectly assigned jobs that no longer existed, causing widespread workflow failures and prompting a throttling of webhook events.
A fix raised the success rate for new workflow runs to roughly 97% and began draining the backlog, but overall runner capacity remains constrained.
Related services such as Copilot, GitHub Pages, and Enterprise Importer migrations also faced delays, and self-hosted runners may encounter registration errors or rate limits.
THE READ
What the cluster adds up to.
The incident originated from a malfunction in the job-dispatch system, where both GitHub-hosted and self-hosted runners received assignments for jobs that had already been cancelled or completed. This mismatch caused a cascade of failed workflow runs, leaving many queued jobs stuck and preventing new runs from starting promptly. Engineers relying on GitHub Actions saw a sharp drop in job completion rates, with early reports indicating only 30-40% of queued jobs succeeding.
GitHub responded by deploying a corrective change that stops invalid job assignments and begins draining the queued workload. The remediation also introduced throttling of webhook deliveries to manage the recovery load, meaning that only a fraction of push and pull-request events were generating new workflow runs during the incident. While the fix lifted the success rate for newly started runs to about 97%, the overall runner pool remains under pressure, especially for larger standard runners.
Self-hosted runners were not immune; they experienced registration errors and rate-limiting as the platform struggled to reconcile runner state with the backlog. The throttling of webhook triggers further limited the ability of external systems to react to repository events, requiring teams to monitor GitHub’s status page or implement fallback mechanisms. As a result, any automation that depends on immediate webhook processing, such as deployment triggers or external notifications, could be delayed or dropped entirely.
The outage’s ripple effects extended to other GitHub services. Copilot’s code-review and coding-agent features, GitHub Pages, and migrations performed via GitHub Enterprise Importer all reported failures or slowdowns. For organizations that integrate these services into their development workflow, the incident introduced additional points of failure that needed to be accounted for during the recovery window.
From an engineering standpoint, the event underscores the need for resilient CI pipelines. Teams should incorporate retry logic for workflow runs, monitor webhook delivery health, and consider secondary CI providers as a contingency. Additionally, keeping an eye on runner registration health and capacity metrics can help detect similar issues early before they cascade into larger outages.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER