Actions delays in starting runs

lowGitHubActionsAug 24, 2026 13:56Duration: 38m
computestorageapi
Capacity IssueStorage FailureAPI Issue

Summary

On August 24, 2026, between 13:33 UTC and 14:04 UTC, 3.8% of Actions runs experienced start delays over 5 minutes with 1.25% of Actions runs failing outright. <br /> <br />The incident was caused by a disk failure on a node hosting one of many service instances responsible for processing runner assignment events. Typically, pods on unhealthy nodes are removed and replaced automatically without impact. In this case, although the node was severely degraded and unable to perform disk operations, i

Impact

minor

Timeline

Aug 24, 2026 13:56

[investigating] We are investigating reports of degraded performance for Actions

via statuspage
+26m
Aug 24, 2026 14:22

[investigating] Failures while queuing and running Actions jobs for a subset of customers are now resolving. We are monitoring for full recovery.

via statuspage
+3m
Aug 24, 2026 14:26

[monitoring] The degradation affecting Actions has been mitigated. We are monitoring to ensure stability.

via statuspage
+9m
Aug 24, 2026 14:34

[resolved] This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

via statuspage
+0m
Aug 24, 2026 14:34

[resolved] On August 24, 2026, between 13:33 UTC and 14:04 UTC, 3.8% of Actions runs experienced start delays over 5 minutes with 1.25% of Actions runs failing outright. <br /> <br />The incident was caused by a disk failure on a node hosting one of many service instances responsible for processing runner assignment events. Typically, pods on unhealthy nodes are removed and replaced automatically without impact. In this case, although the node was severely degraded and unable to perform disk operations, it continued sending healthy signals, preventing the system from immediately moving its work elsewhere. During this period, events assigned to the affected component accumulated until an automatic rebalance redirected processing to healthy components at 13:54 UTC. The queue backlog was cleared at 14:00 UTC, and processing returned to normal by 14:04 UTC. <br /><br />To prevent a recurrence, we are improving detection and automated remediation for unhealthy nodes that aren’t fully offline. We are also strengthening application-level resiliency, so stalled consumers are automatically removed quickly and their work reassigned without waiting for the affected node to recover.

via statuspage

Lessons Learned

GitHub has experienced 148 incidents in the past year. This frequency suggests systemic reliability challenges that may warrant additional monitoring.

📊Incidents related to compute, storage, api have occurred 1049 times across all providers in the past year. This is one of the most common failure categories in cloud infrastructure.

💡This incident is categorized as: Capacity Issue, Storage Failure, API Issue. Consider implementing preventive measures specific to this failure category.