This post, published April 28, 2026 by GitHub CTO Vlad Fedorov, addresses two recent incidents outside the normal monthly availability report cadence: “Both of those incidents are not acceptable, and we are sorry for the impact they had on you.”
GitHub began executing a plan to increase capacity by 10X in October 2025, aiming to substantially improve reliability and failover. By February 2026, it was clear GitHub needed to design for a future requiring 30X today’s scale. The main driver is a rapid change in how software is being built: since the second half of December 2025, agentic development workflows have accelerated sharply, with repository creation, pull request activity, API usage, automation, and large-repository workloads all growing quickly. This growth stresses many systems simultaneously—a single pull request can touch Git storage, mergeability checks, branch protection, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases—so at high scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can affect several product experiences.
GitHub’s stated priorities are availability first, then capacity, then new features.
What we’re doing
In the short term, GitHub resolved bottlenecks that appeared faster than expected by moving webhooks off MySQL to a different backend, redesigning the user session cache, redoing authentication and authorization flows to reduce database load, and leveraging its migration to Azure to stand up more compute. GitHub then focused on isolating critical services like Git and GitHub Actions from other workloads and minimizing single points of failure, starting with careful analysis of dependencies and traffic tiers, and accelerated migrating performance- or scale-sensitive code out of its Ruby monolith into Go. GitHub also began working on a path to multi-cloud as a longer-term measure for resilience, low latency, and flexibility, and has been investing heavily in response to the rise of large monorepos, including optimizing merge queue operations.
Recent incidents
April 23 merge queue incident
On April 23, pull requests experienced a regression affecting merge queue operations. Pull requests merged through the merge queue using the squash merge method produced incorrect merge commits when a merge group contained more than one pull request. 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 (GitHub noted its initial numbers were intentionally conservative and slightly higher). The issue did not affect pull requests merged outside the merge queue, nor merge queue groups using the merge or rebase methods. There was no data loss—all commits remained stored in Git—however, the state of affected default branches was incorrect, and GitHub could not safely repair every repository automatically. GitHub said this incident exposed multiple process failures that are being changed to prevent recurrence.
April 27 search-related incident
On April 27, an incident affected GitHub’s Elasticsearch subsystem, which powers several search-backed experiences including parts of pull requests, issues, and projects. The cluster became overloaded—likely due to a botnet attack—and stopped returning search results. There was no data loss, and Git operations and APIs were not impacted; however, parts of the UI that depended on search showed no results, causing significant disruption. GitHub noted this was one of the systems not yet fully isolated to eliminate as a single point of failure, because other areas had been higher priority in its risk-prioritized reliability work.
Increasing transparency
GitHub said it recently updated its status page to include availability numbers and has committed to statusing incidents both large and small, and is working on better ways for customers to report incidents and share signals during disruptions.
Our commitment
GitHub committed to improving availability, increasing resilience, scaling for the future of software development, and communicating more transparently along the way.
Editor’s note: This post was updated on April 28, 2026, to update the number of repos affected during the April 23 incident.