The continuous integration and delivery service recorded 99.33% uptime over the 90 days to August 19, equivalent to roughly 14.5 hours of unavailable time. By comparison, GitHub’s core Git Operations service, covering fundamental activities such as pushing, pulling and cloning code, maintained 99.99% availability over the same period.
The divergence highlights how reliability varies considerably across different parts of the GitHub ecosystem. While the underlying repository infrastructure has remained highly stable, Actions has faced repeated disruptions affecting the automated workflows developers use to build, test and deploy software.
A major Actions disruption on August 6 lasted from 15:05 UTC until 00:14 UTC the following day, a period of more than nine hours. At the peak, 71% of workflow runs suffered infrastructure failures. Of those that remained functional, 75% were delayed by more than five minutes. Both GitHub-hosted and self-hosted runner users were affected.
That single disruption exceeded the roughly 8.8 hours of annual downtime implied by 99.9% availability, although contractual service-level calculations can differ depending on the service, customer agreement and measurement methodology.
The August 6 failure began when a routine deployment to an internal service handling events and job generation exposed an existing capacity and concurrency weakness. Replacement of application pods reduced available capacity, remaining resources became saturated and failures cascaded through multiple clusters and downstream systems.
Recovery was complicated by an accumulated backlog and a latent flaw in job assignment. Some runners repeatedly picked up jobs that were no longer valid and became trapped retrying them rather than processing legitimate work. Capacity expansion, throttling of incoming webhook-triggered workloads and changes to the job-assignment process eventually cleared the queues.
GitHub subsequently acknowledged that the duration and impact of the incident fell short of its availability commitments and accelerated plans to shift more of the Actions architecture to Microsoft Azure. Although much of the workload already runs on Azure, a central service connecting GitHub’s monolithic application to Actions was still operating entirely within GitHub’s own data centres when the failure occurred.
Reliability came under renewed pressure on August 17 when a much broader GitHub. com outage affected Issues, Pull Requests, APIs, Actions and Copilot. The overall incident lasted seven hours and 47 minutes, although Actions itself recovered earlier, at about 18:03 UTC after roughly four-and-a-half hours of degradation.
At the height of that disruption, web and API error rates reached approximately 20%, while archive and raw-content downloads suffered error rates of about 50%. Authentication systems including SAML and OIDC were affected alongside SCIM provisioning and Team Sync.
The failure originated with network saturation on load balancers in GitHub’s Central US data centre after traffic reached a new peak. An Istio sidecar pod reached its concurrency limit but failed to scale correctly because of a configuration policy that monitored the host service rather than the sidecar limits. The resulting cascade eventually exhausted flow capacity on four HAProxy nodes.
Retry mechanisms then amplified the disruption. Copilot Token Service traffic, normally running at roughly 7,000 to 9,000 requests per second, surged to between 70,000 and 100,000 requests per second as client behaviour repeatedly generated additional authentication requests. GitHub reduced gateway retries and temporarily blocked selected traffic before gradually restoring services.
Actions had already shown signs of instability before August. On July 25, two connected degradations disrupted workflow processing after problems involving a critical Redis cluster. During the more severe period, 60% of workflow runs suffered infrastructure errors and 30% were delayed by more than five minutes.
The pattern is increasing attention on concentration risk within software delivery pipelines. Organisations that rely entirely on one hosted CI/CD platform can face delayed releases, interrupted security patches and failed automated deployments even when their own infrastructure remains healthy.
Follow Arabian Post
Select Arabian Post as your preferred source on Google and MSN News for trusted business news and Arab politics and updates.
