Product1 publisher2 min readPublished
Growth in Actions and Copilot outpaced GitHub's shared infrastructure in three of five August incidents
After five incidents in August 2026, GitHub says its shared infrastructure has not kept up with Actions growth. Which services failed together is the part platform teams can plan around before the next one.
The Product Desk · Product desk
What happened
- A routine deployment on August 6 cut pod capacity in one datacenter, and the resulting cascade took out Actions runners, Copilot's coding agent, code review, Pages builds, Dependabot and repository migrations for about nine hours.
- An August 17 traffic peak exceeded datacenter load balancer limits and degraded shared authentication, with the front-door failure rate peaking at 56% and about 29,000 organizations seeing errors across roughly 4.8 million requests.
- On August 20 an upstream managed database outage left Copilot cloud agent tasks running while status and results lagged up to 90 minutes at more than 54 organizations over nearly 11 hours.
- Database saturation on August 26 hit Actions run starts, Pages deployments and Copilot code review, with at least 24 organizations seeing run-start failures and 386 organizations feeling some impact.
- On August 27, 63% of Copilot requests routed to the Kimi K3 model failed because of a problem at the upstream model provider.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- exposure When one incident removes Actions and code review together, there is no fallback left inside GitHub, so the manual deploy path has to live somewhere else and be rehearsed by someone who owns it.
- constraint Two of the five failures started with suppliers GitHub does not operate, so however much capacity GitHub adds, that part of Copilot's reliability stays outside any commitment it can make.
- decision Client-side retry settings stop being a library default and become a platform decision, because a retry bug in callers helped drive the August 17 authentication load.
- precedent With capacity ranked above features in GitHub's own stated order, teams planning quarters around announced Copilot capability should expect datacenter work to take the slot first.
GitHub's August report opens with its own ordering: "Availability, then capacity, then features." [2] Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group [13], said that ordering is correct. "Ordering availability ahead of features is the right call," Ashley said [14].
Most teams still carry GitHub in their heads as source control with CI attached. The August list puts Copilot in all five incidents and Actions in three [17]. GitHub named the cause without much hedging: "Our shared infrastructure services have not kept up with our month-over-month actions growth and peak load." [11] The August 6 postmortem said the same thing about a different day: "The affected actions services were running close to their capacity and concurrency limits." [4] The repair list there was a rollback, added capacity, and a fix for a latent bug that had let runners accept jobs they could not run [5].
Divide the August 17 request errors by the organizations that saw them and the average affected organization got roughly 166 failed requests [18]. Some of that volume came from customer code, not from GitHub. "A latent client retry bug sharply amplified traffic to one internal authentication endpoint," GitHub said [8]. Retry defaults in your own clients are part of GitHub's peak load.
Three of the five incidents trace to capacity limits inside GitHub's own services; the other two began with an upstream provider GitHub does not run [19]. Capacity work at GitHub does not touch that second leg.
Two questions sort every GitHub dependency you have. Does a failure stop the work or only hide it, and is the failing component GitHub's or someone else's. August 26 is stop-work and GitHub's, and the answer is a deploy path you can run by hand, which is the first item on the resilience list devops.com puts to engineering leaders [16]. August 20 is hide-work and upstream, and nothing in your alerting fires. "The Copilot agent incident showed why: tasks kept running while status lagged, so teams could not tell what had finished. Engineering leaders should require agent status checks they own, outside any vendor's UI," Ashley said [15]. August 27 is stop-work and upstream, and other models were unaffected, so the fallback is a second model route configured before the day you need it [12]. GitHub's own recovery on August 26 was manual throttling [10].
What to watch
- Whether GitHub's September report shows Actions run-start failures again after August 26's manual throttling.
- Whether GitHub publishes per-service concurrency or capacity headroom that customers can plan builds against.
- Whether Copilot gains a documented model fallback path after 63% of Kimi K3 requests failed.