An Update on GitHub Availability
GitHub's CTO describes two April 2026 incidents — a merge queue squash regression affecting 658 repositories and an Elasticsearch overload — as symptoms of an architecture that hasn't yet caught up with the 30x scale demanded by agentic development workflows.
GitHub’s April 2026 incidents were not simply two unrelated outages. They were the architecture making itself visible — coupling that existed at normal load but could only be seen at the scale agentic workflows created in a matter of months.
Source
An update on GitHub availability
By: GitHub (Vlad Fedorov, CTO)
Published: Apr 28 2026
Type: Engineering article
This post connects two distinct incidents to a larger architectural argument about what happens when a platform’s usage model changes faster than its system design can be revised. The CTO’s explicit prioritization — availability first, capacity second, new features third — and the honest accounting of where work hadn’t yet reached are both worth sitting with.
How Exponential Growth Exposes Hidden System Coupling
Vlad Fedorov’s April 28 post covers two incidents that occurred within five days of each other, but it is not really about the incidents. It is about the compounding effect of a new scale regime on a system designed for a different one — and about the kind of architectural work that has to happen before the next failure can be prevented, not merely recovered from.
GitHub began planning for a 10x capacity increase in October 2025. By February 2026, that target had been revised upward to 30x. The driver was the sharp acceleration in agentic development workflows in the second half of 2025. Agents interact with GitHub at machine speed and volume: creating repositories, opening pull requests, checking merge queue status, querying APIs, and triggering GitHub Actions across thousands of concurrent sessions. The load profile changed structurally, not just in volume. Repository creation, pull request activity, API usage, and large-monorepo workloads were all growing simultaneously.
The post enumerates what a single pull request actually touches: Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. This is not just architecture documentation — it is a blast radius map. When any one of those dependencies slows under load, the failure propagates outward. Queues deepen. Cache misses convert to database queries. Retries amplify the traffic they were meant to absorb. A single slow dependency can degrade several product experiences at once, and the degradation compounds across the chain of dependencies rather than staying contained to the origin.
The April 23 incident made this coupling concrete in a specific and damaging way. A regression in the merge queue affected pull requests using the squash merge method when a merge group contained more than one PR. Subsequent merges in the group were producing incorrect merge commits — in affected cases, changes from earlier merges were inadvertently reverted by later ones, leaving the default branch of affected repositories in an incorrect state. GitHub confirmed no data loss: all commits remained in Git history. But 658 repositories and 2,092 pull requests were left in a state that could not be automatically repaired. The framing in the post is telling: this incident exposed multiple process failures, not just a single bug. The regression itself was the mechanism; the process gaps were what allowed it to reach production and to affect this many users before being caught.
The April 27 incident had a different character. The Elasticsearch cluster that powers search-backed experiences across pull requests, issues, and projects became overloaded — likely due to a botnet attack, the post says — and stopped returning results. Search-backed UI components showed no content. Git operations and APIs continued working without interruption. There was no data loss. The damage was entirely a function of Elasticsearch being a single point of failure for features that depended on it. The post is direct about why: search isolation had been deprioritized behind other reliability work that was assessed as higher risk. The team knew this was a gap; it simply hadn’t moved far enough up the queue before the April 27 attack hit.
These two incidents together sketch the problem Fedorov is describing at the level of organizational priorities, not just system design. Isolating a dependency is architectural work with a non-trivial cost — it requires understanding the dependency graph, finding safe abstraction boundaries, migrating callers, and running old and new paths in parallel long enough to validate correctness. At GitHub’s scale and with a codebase that includes a large Ruby monolith, this work doesn’t happen quickly. The task isn’t to fix the thing that just broke; the task is to work through a risk-prioritized queue of coupling problems before each one becomes an incident. The April 2026 outages reflect what happens when that queue runs behind the rate at which the system’s scale is increasing.
The work Fedorov describes — migrating performance-sensitive paths from Ruby to Go, isolating Git and GitHub Actions from other workloads, redesigning session caches and authentication flows to reduce database load, redesigning the merge queue for repositories with thousands of pull requests per day, pursuing multi-cloud deployment — is all isolation work. Each item reduces the blast radius of a failure in one subsystem affecting others. None of it is glamorous. It is the kind of work that is easy to defer in favor of features and easy to justify deferring right up until an incident makes the cost visible.
The prioritization statement — availability, then capacity, then features — is one of those things that every engineering team agrees with in principle and struggles with in practice. The April 2026 incidents are a data point about what the pressure of that backlog actually looks like at scale: two incidents in five days, one a correctness regression and one a capacity failure at a dependency, both traceable to coupling that existed in the system well before the incidents and that the team was already working to address.
My take
This post reveals that reliability at scale is not a fixed property of a system — it is a property of a system at a given load and usage model. An architecture that is reliable at 1x may have dozens of hidden assumptions that fail at 10x. The shift to agentic workflows didn’t break GitHub; it brought the load to the threshold where coupling that had always existed became the dominant failure mode. The lesson isn’t specific to GitHub’s stack: it is that blast-radius reduction is architecture work that has to precede the scale increase it’s designed for, not follow it.
Where this is useful
- Evaluating whether an existing service’s dependency graph has been analyzed for blast-radius risks before a major load increase (agentic traffic, viral growth, a new high-volume integration)
- Understanding why blast-radius reduction cannot be solved by monitoring alone — you have to pull dependencies apart before an incident, because observing coupling during a failure doesn’t fix the coupling
- Reviewing whether a team’s prioritization framework (availability before capacity before features) is reflected in the actual backlog, or only in stated values
- Not when: the system is well within its design envelope and load growth is gradual and predictable — coupling analysis becomes urgent only as load approaches the regime where small inefficiencies start to compound
Apply this: Map the full dependency graph of your most critical user-facing action and ask which dependencies have no fallback or degraded mode if they slow by 10x.
What I want to remember
Remember: Hidden coupling is only hidden at normal load — scale reveals the dependencies you forgot to isolate.