Degraded availability for GitHub Actions, GitHub Pages and Webhooks
Facts
- Source
- GitHub Status · original
- Started
- (25 days ago)
- Ended
- · lasted 1 h 8 min
- How it ended
- Microsoft marked it resolved.
- First captured by us
- Last changed
- (43 min ago)
- Affected services
- GitHub Actions, GitHub webhooks, GitHub Pages
Last text from Microsoft
On October 19, 2026, between 15:24 and 16:52 UTC, GitHub Actions, GitHub Pages, and webhooks generated by Actions were degraded. Live updates on GitHub.com and code search were also degraded for part of this time. No data was lost. <br /><br />Impact <br /><br /> - Workflow status updates, logs, and checks were delayed. <br /> - 5.13% of jobs on GitHub-hosted runners were delayed in starting, and 0.02% of workflow runs failed. <br /> - During the first 30 minutes, 8.47% of requests to the Actions jobs REST API returned errors. <br /><br />Pages deployments and webhooks generated by Actions runs were delayed. <br /><br />An internal Actions service that stores logs and run status lost connections to some of its cache servers in one cloud region and immediately retried them from every server at once. The resulting surge of new connections overloaded a shared network link between our data center and that region, which also disrupted other services that use the same link. We mitigated the incident by moving the Actions service off the affected cache servers and reducing connections from other services on the link. We then processed the delayed Actions work. We are continuing to investigate the cause of the initial connection timeouts. <br /><br />We were already in the process of rolling out a limit on how quickly this service can open new connections, but it was still in shadow mode (logging only, not enforcing) at the time of the incident. We have since fully enforced it and capped the service's concurrent connection attempts. We are extending these limits to other Actions services, adding backoff to retries, limiting how much shared network capacity a single service can use, and improving alerting so we can find the source of connection surges faster.
Quoted from GitHub Status (source), captured . Reproduced for reporting and archival purposes.
Official updates
Posted by GitHub Status, newest first.
Resolved
On October 19, 2026, between 15:24 and 16:52 UTC, GitHub Actions, GitHub Pages, and webhooks generated by Actions were degraded. Live updates on GitHub.com and code search were also degraded for part of this time. No data was lost. <br /><br />Impact <br /><br /> - Workflow status updates, logs, and checks were delayed. <br /> - 5.13% of jobs on GitHub-hosted runners were delayed in starting, and 0.02% of workflow runs failed. <br /> - During the first 30 minutes, 8.47% of requests to the Actions jobs REST API returned errors. <br /><br />Pages deployments and webhooks generated by Actions runs were delayed. <br /><br />An internal Actions service that stores logs and run status lost connections to some of its cache servers in one cloud region and immediately retried them from every server at once. The resulting surge of new connections overloaded a shared network link between our data center and that region, which also disrupted other services that use the same link. We mitigated the incident by moving the Actions service off the affected cache servers and reducing connections from other services on the link. We then processed the delayed Actions work. We are continuing to investigate the cause of the initial connection timeouts. <br /><br />We were already in the process of rolling out a limit on how quickly this service can open new connections, but it was still in shadow mode (logging only, not enforcing) at the time of the incident. We have since fully enforced it and capped the service's concurrent connection attempts. We are extending these limits to other Actions services, adding backoff to retries, limiting how much shared network capacity a single service can use, and improving alerting so we can find the source of connection surges faster.
Monitoring
Actions, Pages and Webhooks are operating normally.
Investigating
We’re seeing recovery following mitigation and are continuing to monitor. <br /><br />Customers may still experience delays in GitHub Actions workflow status updates, GitHub Pages deployments, and check and workflow webhook events generated by Actions runs.
Investigating
We’re are currently investigating degraded availability affecting GitHub Actions, GitHub Pages and Webhooks. <br /><br />Customers may experience delays in workflow processing, site builds and webhook delivery.<br />
Investigating
Webhooks is experiencing degraded performance. We are continuing to investigate.
Investigating
We are investigating reports of degraded performance for Actions and Pages
What Microsoft changed
Microsoft edits the text of an incident in place. We keep every version we capture (checked every minute) and highlight the difference. Removed text is struck through, added text is marked.
First version we captured
Captured · Microsoft's own timestamp · revisiond9j2ctrcOriginal text as we first saw it
On October 19, 2026, between 15:24 and 16:52 UTC, GitHub Actions, GitHub Pages, and webhooks generated by Actions were degraded. Live updates on GitHub.com and code search were also degraded for part of this time. No data was lost. <br /><br />Impact <br /><br /> - Workflow status updates, logs, and checks were delayed. <br /> - 5.13% of jobs on GitHub-hosted runners were delayed in starting, and 0.02% of workflow runs failed. <br /> - During the first 30 minutes, 8.47% of requests to the Actions jobs REST API returned errors. <br /><br />Pages deployments and webhooks generated by Actions runs were delayed. <br /><br />An internal Actions service that stores logs and run status lost connections to some of its cache servers in one cloud region and immediately retried them from every server at once. The resulting surge of new connections overloaded a shared network link between our data center and that region, which also disrupted other services that use the same link. We mitigated the incident by moving the Actions service off the affected cache servers and reducing connections from other services on the link. We then processed the delayed Actions work. We are continuing to investigate the cause of the initial connection timeouts. <br /><br />We were already in the process of rolling out a limit on how quickly this service can open new connections, but it was still in shadow mode (logging only, not enforcing) at the time of the incident. We have since fully enforced it and capped the service's concurrent connection attempts. We are extending these limits to other Actions services, adding backoff to retries, limiting how much shared network capacity a single service can use, and improving alerting so we can find the source of connection surges faster.