GitHub Actions and Pages Hit by Major Outage, Recovery Ongoing

GitHub Actions and Pages Hit by Major Outage, Recovery Ongoing

GitHub's automation and hosting services experienced a significant outage on August 6, 2026, causing widespread disruption for developers relying on CI/CD pipelines and static site hosting. The incident, which began at 15:22 UTC, quickly escalated to affect multiple interconnected services, including Copilot and GitHub Enterprise Importer, before a partial recovery was achieved. The company has since shared a detailed timeline and recovery steps, but the event highlights the fragility of critical development infrastructure.

The outage started with reports of degraded performance for GitHub Actions, followed within minutes by confirmation of degraded availability. Users quickly encountered failed workflow runs, delayed job starts, and errors from the Actions REST API. Unexpected rate limiting was also reported, adding to the frustration. GitHub engineers identified the source of the disruption and began deploying mitigations, but the situation remained unresolved for hours.

Ripple Effects: Pages, Copilot, and Enterprise Importer

As the incident unfolded, the impact spread beyond Actions. GitHub Pages, the static site hosting service, was added to the list of affected systems, with users experiencing degraded performance. More surprisingly, Copilot code review and Copilot coding agent were also impacted, along with migrations using GitHub Enterprise Importer. Webhook deliveries were delayed, and hosted runners faced capacity constraints, causing jobs to queue for extended periods or time out entirely.

The interconnected nature of these services underscores the complexity of GitHub's infrastructure. A problem in one area can cascade, affecting tools that developers have come to rely on for daily operations. For many teams, this meant blocked releases, delayed deployments, and stalled development workflows.

Recovery Timeline and Lingering Issues

GitHub's status page provides a detailed timeline of the recovery efforts. By 20:34 UTC, the company noted that capacity remained constrained and that self-hosted runners might see registration errors. At 21:30 UTC, webhook triggers were still throttled, processing only about 15% of events, with job success rates at 65%. The situation improved gradually, with success rates climbing to 97% by 22:18 UTC and 99% by 23:13 UTC.

However, even after the incident was marked resolved at 02:04 UTC on August 7, lingering issues remained. Some Actions Runner Controller (ARC) runner pods were stuck in an idle state, requiring manual intervention. Users were advised to delete those pods using kubectl or redeploy their ARC application. Additionally, certain workflow-triggering events, such as push and pull request events, were not processed during the incident and cannot be replayed automatically, meaning users may need to re-trigger workflows manually.

Root Cause and Future Prevention

While GitHub has not disclosed the root cause, the company has stated that a detailed analysis will be shared. The incident involved runners being assigned invalid jobs, leading to a backlog that delayed processing. The company deployed fixes and implemented automatic recovery mechanisms in future releases of Actions Runner and Actions Runner Controller to prevent similar issues.

This outage is a reminder of the critical role GitHub plays in the software development ecosystem. For many organizations, GitHub Actions is the backbone of their CI/CD pipeline, and any disruption can have significant business implications. The fact that Copilot and Pages were also affected highlights the need for robust incident response and communication, which GitHub provided through its status page.

As development teams recover from this incident, they should review their own processes for handling such disruptions. Implementing fallback strategies, monitoring status pages, and understanding the limitations of managed services are all prudent steps. GitHub's commitment to sharing a root cause analysis will be valuable for the community, helping to build trust and improve resilience.

For now, the service is stable, but the incident serves as a stark reminder of the dependencies that modern software development has on cloud-based tools. The ability to quickly adapt and recover is essential, and GitHub's response, while not perfect, demonstrated a commitment to transparency and resolution.