GitHub 7月可用性报告：Actions 事故与 Azure 迁移

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 automation, review controls, and operational safeguards, so customer experience is less dependent on perfect human execution.

Crossing 50% is the midpoint, not the finish. The next phase is about building enough independent Azure capacity to serve all production traffic and, ultimately, withstand the loss of a region without failure. This quarter, we are targeting 70% of read traffic and 30% of write traffic in Central US while bringing every production service online there. Moving database primaries will unlock write traffic; a second Azure region will provide the foundation for regional resilience. We now have a line of sight to get dotcom production traffic out of our datacenters by the end of CY2026.

The eight incident write-ups that follow are the other half of this picture—what the system did well, what it did not, and what we have already changed as a result. The principle continues to guide us: availability, then capacity, then features.

July 8, 2026 (lasting 7 hours and 4 minutes)

On July 8, 2026, between 15:07 and 22:13 UTC, multiple GitHub services—including the Web UI, REST API, GraphQL API, Actions, Packages, Copilot, and Git operations—were unavailable across data-resident Enterprise Cloud environments and returned 5xx errors. Affected users experienced page-load and login failures, failed API requests, queued or rejected Actions workflow runs, and unavailable package registry endpoints. During the peak hour, approximately 84% of active tenants across the affected production environments had a majority of their requests fail, and the peak 5xx error rate reached approximately 96% in the most affected environment.

Our automated monitoring detected elevated 5xx errors within approximately 19 minutes of the first impact.

An automated infrastructure metadata process changed a runtime configuration value across virtual machines in these affected environments. A safeguard that normally prevents this value from changing on running machines did not apply to this update. The incorrect value disrupted service discovery and left traffic routers without available backends. We mitigated the incident by restoring the correct configuration values in each of the affected environments and allowing services to re-register. Recovery took several hours because the values had to be corrected and validated across many machines. A separate infrastructure component exhausted its available memory during the recovery and required additional mitigation, extending the recovery duration. We are enforcing metadata immutability, removing unsafe overwrite behavior, and improving staged rollouts. In addition, we are investing in improving monitoring for empty traffic-router backend pools; and developing safer fleet-wide recovery tooling. These changes are intended to prevent recurrence and reduce detection and mitigation for similar issues in the future.

July 9, 2026 (lasting 9 hours and 18 minutes)