GitHub Had Five Outages in August. They Share One Cause

GitHub logged five incidents in August 2026 that degraded Actions, Copilot, pull requests, Pages and Dependabot, with the longest lasting 9 hours and 54 minutes, the company said in its August 2026 availability report, posted to the GitHub Blog by Jakub Oleksy on Sept. 9, 2026.

The first hit on Aug. 6 at 15:22 UTC and ran 10 hours and 42 minutes, degrading Actions, Copilot's coding agent and code review, Pages, and Dependabot for at least 74 organizations. GitHub traced it to a routine deployment on an internal Actions event-processing service; replacing pods during the rollout briefly cut capacity at one site, pushing the remaining sites past their limit as traffic shifted.

The pattern across five days

The worst incident, on Aug. 17 at 13:40 UTC, ran 7 hours and 35 minutes and pushed the peak failure rate for front-door requests to 56.07 percent. About 29,000 organizations saw at least one failed or slow request, totaling roughly 4.8 million failed or slow requests, GitHub said. A traffic peak overwhelmed one datacenter's load balancers, a service-mesh sidecar hit its concurrency limit without scaling up, and a latent client retry bug amplified traffic into an internal authentication endpoint, degrading sign-in across services that route through that datacenter.

Incident date (UTC)	Duration	Peak customer impact
Aug. 6, 15:22	10h 42m	74+ orgs affected
Aug. 17, 13:40	7h 35m	56.07% of requests failed at peak
Aug. 20, 14:43	9h 54m	37.5% of task-status activity delayed
Aug. 26, 15:11	2h 50m	386 orgs saw some impact
Aug. 27, 10:04	2h 8m	63.3% of Kimi K3 requests failed

1. Aug. 6642 minutes
2. Aug. 17455 minutes
3. Aug. 20594 minutes
4. Aug. 26170 minutes
5. Aug. 27128 minutes

Source: GitHub availability report, August 2026, accessed 2026-09-15

The Aug. 20 incident, at 14:43 UTC and lasting 9 hours and 54 minutes, hit a managed cloud database that stores Copilot cloud agent task status. One region of that database suffered a provider-side outage; the underlying agent tasks kept running and finishing, but at least 54 organizations saw their status and results lag by as much as 60 to 90 minutes.

Two smaller incidents, two different roots

On Aug. 26 at 15:11 UTC, a burst of events pushed an internal database past its tipping point, stalling the service that turns events into Actions runner assignments; runs failed to start or queued far past normal, with more than one in five run starts failing or badly delayed at peak, and no automatic circuit breaker existed to throttle the load before it hit that point.

The last incident, Aug. 27 at 10:04 UTC, was narrower: a serving degradation at the upstream provider behind Copilot's Kimi K3 model option caused 63.3 percent of Kimi K3 requests to fail for 2 hours and 8 minutes, while customers on other models were unaffected.

Where the analysis diverges from the report

GitHub's own writeup treats the month as a capacity problem it is actively fixing: it says job-routing changes moved 33 percent of Actions jobs off a constrained production cluster, cutting peak cache CPU utilization from 98 percent to 80 percent and adding an estimated three months of headroom, and that a database migration to Azure pushed monolith read traffic to a 64.3 percent peak without incident. Away from the five incidents, GitHub said it moved a 24-table authentication-core cohort off its oldest shared database, removing about 1 million queries per second from that database's replicas, while separate query-hygiene work cut another 120,000 queries per second. Git overload protection changes let the service absorb 6.4 percent more traffic while cutting 95th-percentile response duration by 24 percent and maximum delay by 78 percent, changes GitHub said were already in use mitigating the August incidents themselves.

Mitch Ashley, vice president and practice lead for CIO and Technology Buyers and Software Lifecycle Engineering at the Futurum Group, read the same five incidents differently in a DevOps.com analysis, arguing they mark a shift in what GitHub availability even means now that Actions and Copilot sit in the middle of customers' delivery pipelines rather than beside them. When a repository host goes down, Ashley's framing goes, a team loses convenience; when the service running its CI and its coding agent goes down for nearly ten hours, a team's builds and deployments fail directly. His practical advice to engineering teams: keep a manual deployment fallback, monitor agent status independently of GitHub's own status page, and audit retry logic so a GitHub outage does not get amplified the way the Aug. 17 retry bug amplified GitHub's own.

The same growth-outpacing-infrastructure tension applies elsewhere in the ecosystem. GitHub's HydraFusion project, built to route Copilot requests across models to cut inference cost, and Chrome's decision to compress its own release cycle to two weeks are both bets that shipping faster is worth the added operational surface; August's five incidents are what that bet costs when it goes wrong. GitHub has not published a September update yet, and whether the headroom from the August fixes holds through the next traffic peak is the number worth watching next.