GitHub availability report: July 2026 - The GitHub Blog

Try GitHub Copilot app

Attend GitHub Universe

Search

Jakub Oleksy·@jakuboleksy

August 12, 2026

13 minutes

Share:

The GitHub Actions incident on Thursday, August 6, was unacceptable in both its impact and particularity of its duration. Availability continues to be our top priority across all of GitHub. However, with this incident, we have fallen short of our commitments to you. We know how heavily customers rely on actions, and a prolonged outage like this one has a real impact on your productivity and on your trust in us.

We continue to work through a deeper root cause analysis (RCA) on the incident, as there were many aspects in play that we want to fully understand before calling the investigation complete. We’ll update the public summary when our investigation is complete, and we will include the complete details in our August availability post to be published in September.

Aside from immediate repair items discovered through our investigation, we are accelerating our architectural roadmap in GitHub Actions, aligned to our ongoing efforts around isolation, resiliency, and scale.

It’s worth noting that the GitHub Actions service at the core of the aforementioned incident is still fully running in our data centers, a contributing factor to the lack of capacity we experienced. While the majority of actions runs on Azure, we hadn’t yet prioritized migrating launch service, the component that bridges the monolith to actions, due to its generally asynchronous nature and ability to queue work in response to issues. Unfortunately, as outlined in the public summary, cascading failures led to an unacceptable delay in recovery. This is why we are accelerating our move of GitHub Actions to Azure, where we will have more headroom and capabilities to absorb spikes.

On our broader efforts, last month, we shared how a deliberate pause and stronger stability controls changed the way we move production traffic into Azure. In July, those controls allowed us to resume that work with greater confidence while continuing to reduce shared dependencies across GitHub.

The short version of July: GitHub is becoming less dependent on shared infrastructure and individual datacenter locations, giving us more capacity to absorb growth and making failures easier to isolate. This month, more than half of monolith read traffic ran in Azure Central US, authentication data began leaving our oldest shared database, and dedicated services removed substantial load from that shared path.

GitHub can now serve a larger share of customer requests from independent Azure capacity, reducing reliance on any single datacenter while preserving performance. Monolith read traffic served from Azure Central US peaked at 52.75% on July 28 —the first time we consistently remained above the halfway line. Git traffic in Azure reached 47% , up from 43% in June, and 29% of all repositories now have a second replica in Central US, making failover less disruptive when a region degrades. Just as important, the stability validation process introduced after May’s incident is now part of every major traffic expansion, helping us increase capacity without increasing customer risk.

We also reduced shared failure points behind critical customer workflows. The first authentication tables moved from our oldest shared database to dedicated infrastructure, proving the migration pattern for the remaining work. Authentication and permission checks now place substantially less pressure on that shared path: at peak, the dedicated user service offloads more than one million queries per second , while 80% of a major authorization lookup has moved to the isolated service path. Repository content traffic now runs fully from Central US on dedicated infrastructure, and the dedicated pull request service, which already serves anonymous traffic, reached 99.87% parity with the monolith for authenticated reads as we progressively roll all traffic to it. Together, these changes make it less likely that pressure or failures in one part of GitHub will affect unrelated customer activity.

GitHub can now absorb more workload growth before shared infrastructure becomes a source of degradation that affects customers. One production change cut total query time on the artifacts table in half, while caching in the Git authorization path reduced authorization service load by 18.2% , even as request volume grew. Search is also less exposed to the capacity constraints that contributed to earlier incidents: all production search workloads now serve from Central US with additional headroom during demand or infrastructure stress.

We are also changing how we measure and operate reliability. In addition to infrastructure health, we are increasingly measuring the health of important customer workflows such as pull requests so teams can identify degradation earlier. We are continuing to replace high-risk manual production activity with...