GitHub Outage Streak Exposes Copilot's Reliance on a Strained Platform

A week of outages, capped by October 7

For developers who rely on GitHub, early October has brought one incident after another. The worst came on Wednesday, October 7, when GitHub confirmed problems with webhooks, Actions, pull requests and issues. On Downdetector, reports began climbing around 10:50 a.m. ET and passed 2,50011. By 8:31 a.m. PT, the count had gone above 2,60013. GitHub's status page reported that everything was working again shortly after 1 p.m. ET11.

Outlets disagree on how long the outage lasted. One report described it as a worldwide outage of more than two hours16. GitHub's own incident log tells a more specific story. There were two distinct bursts of widespread impact, the first from 15:06 to 15:16 UTC and the second from 16:52 to 17:01 UTC. GitHub said the second was a recurrence of the first, and it said a durable mitigation was in progress2. Status trackers recorded the two incidents as lasting about 1 hour 10 minutes and 47 minutes once monitoring periods are included10. A different aggregator measured the confirmed downtime at 39 minutes and 10 minutes12.

The right reading is somewhere in the middle. The hard failures were short, but the instability stretched across an entire working afternoon in Europe and a morning in the Americas. User reports from that afternoon show what it felt like: internal server errors on git push, 500 pages when opening repositories, pull requests that would not merge, and secrets that could not be reached12.

October 7 was the end of a run, not a one-off. On October 5, a problem assigning Actions runners lasted 3 hours 42 minutes, turned into job failures, and also took down GitHub Pages and billing pages. A second, separate billing incident followed later that night14. On October 6, issues, pull requests and webhooks were degraded, and enterprise migrations were paused for several hours while GitHub checked its fixes2. As of those updates, GitHub had promised root cause analyses for these incidents but had not yet published them142.

Why the AI coding angle is central

It is tempting to treat this as a story about Git hosting. The more important point is that GitHub's AI products are built on the same infrastructure as everything else on the platform. When that infrastructure fails, they fail with it.

GitHub's August 2026 availability report makes this clear. On August 17, a latent retry bug in a client flooded an internal authentication endpoint. A service-mesh sidecar then failed to scale up, and the overload spread through a datacenter's load balancers. Issues, pull requests, the APIs, Actions and Copilot all started returning errors7. At the peak, 56.07% of front-door requests to the affected services failed or were slow, according to GitHub7. Outside reporting on the same event noted that Copilot showed degraded availability roughly 51 minutes after GitHub first confirmed the wider outage8. In other words, Copilot was hit by the shared authentication failure even though Copilot itself was not the problem.

The same report described a roughly nine-hour Actions incident. It affected Copilot coding agent, Copilot code review, Pages builds and Dependabot, and at least 74 organizations had workflows that failed or stayed queued7. A shorter Actions incident on August 26 also delayed Copilot code review, because that feature runs on top of Actions7.

This is the main lesson for teams evaluating AI code review tools. Copilot code review is not a separate service with its own failure modes. It is a workload that runs on CI infrastructure. When Actions run starts fail, automated review stalls with them. On September 28, the dependency showed up directly as an incident titled "Copilot Code Review is unable to complete reviews," which lasted about 51 minutes1018.

The model-provider layer adds a second point of failure

Copilot has another weakness that has nothing to do with GitHub's own servers: the AI labs it routes requests to. On September 17, several OpenAI models available in Copilot, including GPT-5.6 Luna, Terra and Sol, GPT-6 Astra and GPT-5.3-Codex, had degraded availability across Copilot products and IDEs for about 54 minutes. GitHub blamed an upstream provider4. In August, a problem at the provider hosting Kimi K3 caused 63.3% of Copilot requests sent to that model to fail during the impact window7.

Offering many models is a selling point for Copilot, but it also means more things can go wrong. Each new model provider adds another company whose outages show up inside a developer's editor. These model-level incidents do have a mitigating feature, though. They are usually limited to one model family, so developers can often switch to a different model and keep working. When GitHub's own authentication or Actions layer fails, there is no equivalent workaround.

Agentic features have their own unusual failure modes. On August 20, a provider-side outage in one region of the managed cloud database that stores Copilot cloud agent task status caused status and results to lag. In some cases the delay reached 60 to 90 minutes, and at least 54 organizations were affected. GitHub said the tasks themselves kept running to completion and no work was lost7. The incident was frustrating rather than destructive, but it shows that users can lose visibility into autonomous agents even while the agents keep working.

Is AI demand causing the outages?

The strongest claim in the coverage is that AI agents are not only affected by GitHub's instability but are partly causing it. One analysis argues that commits, pull requests and Copilot sessions generated by agents are reaching GitHub faster than its infrastructure can absorb them. It cites a Microsoft spokesperson telling Business Insider that a spike in agentic development starting late last year had "tested our infrastructure's limits"16. The same piece reports that GitHub's internal capacity targets rose from a planned tenfold increase to about thirtyfold. It also says Microsoft has turned to AWS for emergency GitHub capacity, even though it had planned to run GitHub entirely on Azure by 2027. Microsoft has confirmed that it uses multiple cloud providers but has not described the AWS arrangement16.

GitHub's own postmortems point in the same direction, though they stop short of saying so outright. The August 17 failure began with "a new peak in traffic" pushing load balancers toward their limits7. That fits a platform running close to its capacity. It does not prove that agent traffic was the cause of that particular event. For now, the agent-load explanation is plausible and has some official support, but there is not yet a published root cause that confirms it.

Taken together, the reporting supports this conclusion: the outage pattern is structural, not random bad luck. Trackers counted 72 incidents in the 90 days to October 9, and 29 of them were rated major or critical10. Another monitor counted 18 outages across eight components in 30 days18.

Uptime numbers that don't match what developers see

The coverage also reveals a gap between how monitors measure GitHub and what developers actually experience. UptimeRobot's probes reported github.com at 99.998% availability over 30 days19. Its probes of GitHub's authentication and raw-content endpoints stayed green through the October 5 Actions incident14. Copilot-specific monitors showed similar results: one reported 99.93% uptime over 30 days2, and another recorded no incidents at all on the Copilot API endpoint3.

These figures are not wrong. They measure the wrong things. As UptimeRobot itself pointed out, a CI pipeline can be stuck for hours while the endpoints that synthetic probes check keep responding normally14. The same applies to AI tools. Copilot completions can work fine while Copilot code review cannot run, because the failure is in Actions and not in the model API.

What engineering teams should take from this

We draw three practical conclusions. First, if your team's review process depends on an AI reviewer, treat that reviewer as part of your CI system, with the same fallback plans you would have for builds that won't start. Second, pick a backup model in Copilot ahead of time, because upstream provider failures are frequent but usually limited to one model. Third, watch the specific components your team uses, such as Actions, Copilot code review and the agent's task status, instead of relying on headline uptime figures.

There is some reassurance. GitHub's incident reports consistently show no loss of repository data, even during long disruptions16. The underlying tension remains, however. GitHub is selling AI agents that produce more of the traffic its infrastructure is struggling to handle. Until promised capacity increases and root cause analyses arrive, developers should expect GitHub to remain unreliable for some time.