GitHub Actions outage blocks CI jobs and Copilot coding agents

Hosted-runner capacity constraints left CI jobs queued or failing for more than three hours during the US workday.

By · Published

Why it matters

GitHub uses Actions to run CI, Pages, Copilot agents, code reviews and migrations. Runner failures can now block several stages of software delivery at once.

GitHub Actions outage blocks CI jobs and Copilot coding agents — Hosted-runner capacity constraints left CI jobs queued or failing for more than three hours during the US workday.

GitHub Actions suffered a major outage on August 6th, stalling software builds and deployments while disrupting GitHub Pages, Copilot coding agent, Copilot code review and enterprise migrations. GitHub said workflow runs were failing, remaining queued for extended periods or timing out as hosted-runner capacity stayed constrained. (githubstatus.com)

GitHub first acknowledged degraded Actions performance at 15:22 UTC, or 11:22 a.m. Eastern. By 16:33 UTC, GitHub had classified both Actions and Pages as suffering major outages. The incident remained under investigation at 18:46 UTC, more than three hours after it began, with GitHub warning that recovery was taking longer than expected. (githubstatus.com)

The disruption hit jobs using GitHub-hosted runners particularly hard. Self-hosted runners offered no clean escape: GitHub said those customers could encounter errors or rate limits when registering runners. Earlier updates also reported errors from the Actions REST API, unexpected workflow rate limiting and jobs that failed after they had already started. Webhook deliveries could be delayed. (githubstatus.com)

Core repository functions remained available. Git operations, pull requests, issues, packages and general API requests were listed as operational, narrowing the outage's center of gravity to the automation used to test, build and deploy code. For engineering organizations that require passing checks before merging or use Actions to release software, an available repository does little to keep the delivery pipeline moving. (githubstatus.com)

Developers quickly recognized the pattern. Ryan Brewer (@ryanbrewer) wrote, "Another day another github outage." Aida Issayeva (@Aida_Isay) said back-to-back Actions incidents were becoming routine and described checking GitHub's status page as the first step when debugging CI. A screenshot she shared showed green uptime histories across most GitHub services, with Actions carrying the red incident marker.

Actions has become GitHub's shared execution layer

The breadth of the August 6th incident reflects how much GitHub now runs through Actions. GitHub's documentation says Copilot cloud agent works inside an ephemeral development environment powered by Actions, where it reads code, makes changes and runs tests. Copilot code review also uses GitHub-hosted runners by default. (docs.github.com)

GitHub Pages can use Actions to build and deploy sites, while GitHub Enterprise Importer moves repositories and organizations into GitHub Enterprise Cloud. The outage therefore reached beyond conventional CI jobs into AI-assisted development, website publishing and infrastructure migrations. GitHub has concentrated several products on the same workflow and compute layer, increasing the operational cost when runner provisioning or orchestration fails. (docs.github.com)

Pages had already experienced a separate deployment-lag incident beginning at 15:03 UTC. GitHub marked that incident resolved at 16:22 UTC, minutes before Pages again showed degraded performance under the broader Actions incident. GitHub subsequently moved Pages to major-outage status alongside Actions. (githubstatus.com)

Reliability pressure was already building

The outage followed a separate Copilot cloud agent failure on August 5th. GitHub said an internal rate limit had been enabled more broadly than intended, delaying every newly submitted cloud agent job between 11:02 and 11:54 UTC. The backlog was cleared by 13:00 UTC. (githubstatus.com)

Actions also suffered repeated disruptions during July. On July 25th, GitHub recorded two periods of degradation tied to regional infrastructure and Redis capacity. During the first period, 25% of workflow runs failed with infrastructure errors; during the second, the failure rate peaked at 60%. On July 29th, an under-provisioned internal service ran out of memory, delaying about 2% of workflows and causing runner-registration failures and API timeouts. (githubstatus.com)

Earlier July incidents involved hosted-runner provisioning, an autoscaling configuration and an expired internal certificate. The individual causes differed, but each failure surfaced in the same place for customers: workflows waited for runners, failed to start or exhausted retries. (githubstatus.com)

That repetition has made GitHub's status page part of routine CI diagnosis. The August 6th outage reinforces the operational risk created as GitHub attaches more products, including its AI agents, to Actions. A failure in that layer can stop tests, releases, reviews, site deployments and automated coding work at the same time.

Reader comments

Conversation for this story loads after sign-in.