Availability, Scale, and Two Recent Outages
Two incidents in late April affected GitHub services, and they highlight the operational challenges that come with the platform’s recent, rapid growth. Both outages are under review, but the engineering response is already underway: a shift in priorities toward availability and isolation, coupled with a significant infrastructure scaling effort.
GitHub began a plan to increase capacity by 10X in October 2025. By February 2026, projections had changed. The acceleration of agentic development workflows since December 2025 has driven sharp increases in repository creation, pull request activity, API usage, automation, and large-repository workloads. The current design target is now 30X today’s scale.
This growth does not strain one system in isolation. A single pull request touches Git storage, mergeability checks, branch protection, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. At high scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can degrade multiple product experiences.
The operating priorities are now clear: availability first, then capacity, then new features. Work is focused on reducing unnecessary load, improving caching, isolating critical services, removing single points of failure, and migrating performance-sensitive paths to systems built for these workloads. This is distributed systems work—reducing hidden coupling, limiting blast radius, and ensuring the platform degrades gracefully under pressure.
The Roadmap to Reliability
Short-term remediation has already addressed several bottlenecks that appeared faster than expected. Webhooks were moved to a different backend out of MySQL, the user session cache was redesigned, and authentication and authorization flows were reworked to meaningfully reduce database load. The migration to Azure has also been leveraged to stand up additional compute capacity.
The next phase focuses on isolating critical services like Git and GitHub Actions from other workloads to minimize blast radius. This begins with a careful analysis of dependencies and traffic tiers to determine what needs to be pulled apart and how to mitigate attacks while preserving legitimate traffic. Changes are addressed in order of risk. In parallel, work continues on migrating performance-sensitive code out of the Ruby monolith into Go.
A longer-term initiative is the path to multi-cloud. While already in the process of moving out of smaller custom data centers into public cloud, GitHub is now planning for a multi-cloud architecture to achieve the resilience, low latency, and flexibility required for the future.
The rise of large monorepos presents a distinct scaling challenge. Over the last three months, there has been heavy investment in both the Git system and the pull request experience to accommodate these workloads. A separate blog post will soon detail this work and an upcoming API design for greater efficiency. Merge queue operations have also been optimized, a key area for repositories processing thousands of pull requests daily.
Incidents: Causes and Corrective Action
The two incidents were distinct in cause and impact, but both underscore the need for the current focus on isolation and blast-radius reduction.
April 23: Merge Queue Regression
On April 23, a regression affected merge queue operations. When a merge group contained more than one pull request and used the squash merge method, incorrect merge commits were produced. In affected cases, changes from previously merged pull requests and prior commits were inadvertently reverted by subsequent merges.
During the impact window, 658 repositories and 2,092 pull requests were affected. Initial numbers shared were slightly higher because the first assessment was intentionally conservative. Pull requests merged outside the queue were unaffected, as were merge queue groups using merge or rebase methods.
There was no data loss; all commits remained in Git. However, the state of affected default branches was incorrect, and not every repository could be safely repaired automatically. The incident exposed multiple process failures, and those processes are being changed to prevent this class of issue.
April 27: Search Subsystem Overload
On April 27, the Elasticsearch subsystem, which powers search-backed experiences across pull requests, issues, and projects, became overloaded and stopped returning results. The overload was likely caused by a botnet attack. There was no data loss, and Git operations and APIs were not impacted. However, parts of the UI that depend on search showed no results, causing significant disruption.
The root cause analysis is still in progress and will be published. This system had not yet been fully isolated from being a single point of failure, as other areas were higher in the risk-prioritized reliability work. The same dependency and blast-radius analysis is now being applied to reduce the likelihood and impact of this type of failure.
Greater Transparency
Feedback has made it clear that customers need more visibility during incidents. The GitHub status page has been updated to include availability numbers. GitHub is now committed to statusing incidents both large and small, so users do not have to guess whether an issue is on their side or GitHub's.
Work continues on improving incident categorization to make scale and scope easier to understand, as well as on better ways for customers to report incidents and share signals during disruptions.
The commitment is to improve availability, increase resilience, scale for the future of software development, and communicate more transparently. The team behind the platform reads the emails, social posts, and support tickets, and takes the impact to heart. The work is ongoing.
