GitHub Availability in April 2026: Merge Queue Corruption, Search Collapse, and What the Status Page Misses

Bottom line up front

GitHub’s April 28 availability post frames the platform’s recent pain as a capacity problem driven by agentic development workflows.¹ The capacity story is real. It is also incomplete. Two incidents in five days exposed two distinct failure classes: a merge queue correctness defect on April 23 that produced incorrect squash merge commits and could revert prior work on default branches,² and an Elasticsearch overload on April 27 that turned search-backed UI surfaces, including pull request lists, into empty pages.⁴ The deeper issue is coupling. Pull requests now sit on top of Git storage, mergeability checks, branch protection, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. GitHub is racing to isolate those paths while load is already past older capacity assumptions.¹

Key judgment

GitHub’s April 2026 availability problem is not primarily an uptime problem. It is a workflow reliability problem. Developers saw missing pull requests, incorrect merge results, delayed Actions jobs, unavailable search-backed pages, and degraded Copilot or agent workflows while some core Git and API paths kept operating. The new transparency page reflects that gap mechanically: Degraded Performance counts as zero downtime in the published uptime calculation, so the headline percentages can stay high while developer pain is acute.⁶

The capacity reframe

GitHub began a 10X capacity plan in October 2025. By February 2026, the company concluded it needed to design for 30X current scale and attributed the shift to agentic development workflows that accelerated after mid-December 2025.¹ The April 28 post cites concrete peaks of 90M pull requests merged, 1.4B commits, and 20M new repositories per month, drawn from the blog’s growth chart.¹ The chart itself does not provide enough public context to independently verify baselines or exact time windows, which is one of the points Hacker News commenters raised when challenging GitHub’s framing.¹⁵

That framing matters because it changes how the rest of the post reads. If the platform is sized for 10X and traffic is heading toward 30X, individual incidents read as growing pains rather than process failures. The April incidents do not fit that read cleanly.

Incident one: merge queue correctness, April 23

This was not a typical outage. It was a correctness failure inside a workflow that developers explicitly trust to serialize and validate merges.

Pull requests merged through merge queue using the squash merge method could produce incorrect merge commits when the merge group contained more than one pull request. Later merges could inadvertently revert changes from earlier merged pull requests or prior commits on the default branch.²

Timeline

• 16:05 UTC, April 23: Faulty change completed deployment.²
• 19:38 UTC: GitHub became aware after increased customer support inquiries.²
• 19:50 UTC: Status page opened an investigation for Pull Requests.²
• 20:43 UTC: Impact window ended.²
• 21:43 UTC: GitHub posted the incident summary.²

The detection gap is the sharp part: about 3 hours and 33 minutes from deployment to awareness. GitHub says the gap exists because automated monitoring did not validate merge correctness for this multi-PR squash merge path.² A correctness defect that only customer reports can surface is, by definition, a monitoring gap rather than a load problem.

Root cause as stated

GitHub describes an incompletely gated code path that changed merge base computation for merge queue ref updates. The code was intended for an unreleased feature but applied to squash merge groups in production. Existing tests primarily covered single-PR merge queue groups, so the multi-PR squash defect reached production unnoticed.² That is feature flag hygiene and test coverage, not capacity.

Affected counts and a live discrepancy

Current official affected counts on the April 28 blog: 658 repositories and 2,092 pull requests.¹ The GitHub Community RCA discussion thread fetched the same day still stated 230 repositories and 2,092 pull requests, a live source discrepancy at the time of writing.³

Earlier public messaging gave a higher PR count. GitHub COO Kyle Daigle posted on X that 2,804 pull requests out of more than 4 million merged on April 23 were affected, roughly 0.07 percent.⁸ GitHub later revised the figure down to 2,092.¹

GitHub also says all commits remained stored in Git. The problem was that affected default branches could carry incorrect state, and GitHub could not safely repair every repository automatically.¹² No object data loss is true and not reassuring. Branch state is what humans and automation read.

Incident two: search collapse, April 27

The second incident is a more familiar failure shape: a shared dependency overloaded under unusual load, then taking visible UI surfaces with it.

GitHub Status recorded failures viewing issues, pull requests, projects, and Actions workflow runs, plus timed out searches.⁴ The April 28 blog says the Elasticsearch cluster became overloaded, likely due to a botnet attack, and stopped returning search results. Git operations and APIs were not impacted.¹

Timeline

• 16:31 UTC, April 27: GitHub opened an Actions degraded performance incident.⁴
• 16:33 UTC: GitHub said customers across GitHub were experiencing search failures, including workflow run failures, projects failing to load, and timed out search requests.⁴
• 17:35 UTC: GitHub said users had intermittent failures viewing issues, pull requests, projects, and Actions workflow runs.⁴
• 18:17 UTC: GitHub cited connectivity issues reaching Elasticsearch.⁴
• 19:50 UTC: GitHub identified and disabled the additional load stressing Elasticsearch clusters.⁴
• 21:33 UTC: Actions, Issues, Packages, and Pull Requests were mitigated.⁴
• 22:46 UTC: Incident resolved.⁴

The April 27 event carried into April 28 as incomplete indexes. GitHub opened a follow-on incident saying /pulls and /repo/pulls pages were not showing all indexed pull requests because Elasticsearch did not contain all indexed documents. GitHub said no pull request data was lost and the cluster was reindexing.⁵

Two failure classes, one developer experience

The PR story has two layers that are easy to conflate but should be kept separate.

The April 23 merge queue path could corrupt default branch state. PRs merged outside merge queue, and merge queue groups using merge or rebase methods, were not affected.¹²

The April 27 and April 28 PR list visibility issue made PRs appear missing because the list pages relied on Elasticsearch-backed query results. The underlying PR data was not lost and was expected to return as indexes rebuilt.⁴⁵

That distinction is the difference between mutated history and unavailable views. From a developer’s chair, both feel like GitHub losing pull requests. From an engineering perspective, only one of them did.

The status page transparency change is doing real work

GitHub’s April 17 transparency update is required context for reading the April 28 post. GitHub introduced per-service 90-day uptime, a new Degraded Performance state, and a calculation in which Major Outage counts as 100 percent downtime, Partial Outage counts as 30 percent, and Degraded Performance counts as 0 percent downtime.⁶

That last clause matters. A service can have visible customer pain without lowering the published uptime percentage if GitHub classifies the incident as Degraded Performance.

At scrape time on April 28, Pull Requests was still in Degraded Performance.⁷ Per-service 90-day uptime visible on the status page: Git Operations 99.78, Webhooks 99.66, API Requests 99.95, Issues 99.77, Pull Requests 99.58, Actions 99.38, Packages 99.97, Pages 99.90, Copilot 99.69, Codespaces 99.48, and Copilot AI Model Providers 100.0.⁷

Actions has the weakest 90-day number among listed core services, and Pull Requests sits second-lowest at 99.58 while currently degraded. April had heavy incident density. A Status API snapshot taken April 28 returned 27 April incidents in the current incident list, including Code Search, Audit Logs, Copilot, Notifications, Pages, Code Scanning, Projects, Pull Requests, Actions, and Packages disruptions.¹⁶

External reaction

External reaction is signal, not proof, but the signal was consistent.

Tom Elliott described the April 23 event as merge queue commits reverting previously merged commits at random and argued it broke the mental contract teams have with Git, because the issue was subtle and hard to unwind after the fact.⁹

Kyle Daigle responded that 2,804 pull requests out of over 4 million merged on April 23 were affected, that impacted customers were contacted directly, and that GitHub was expanding automated test coverage for merge queue operations.⁸

Gergely Orosz posted that pull requests disappeared on GitHub for many users during the April 27 incident and called the reliability trend unacceptable over the prior months.¹⁰

Mario Rodriguez explained on X that many GitHub pages use Elasticsearch to reduce direct reads against primary databases, including PR lists, issue lists, releases, and other artifact views. When Elasticsearch was impacted, pages could load but query-backed results could fail or return empty.¹¹ That detail matches the April 28 follow-on incident note about incomplete PR results during reindexing.⁵

Hacker News reaction was mostly skeptical of GitHub’s framing. Themes included distrust of unlabelled growth charts, frustration that reliability was allegedly being prioritized while visible feature changes continued, and debate over whether the Azure migration and multi-cloud language implied Microsoft could not get enough reliability from Azure alone.¹⁵

InfoQ summarized GitHub’s own framing of the recent outages as scaling challenges and architectural weaknesses, which is closer to GitHub’s preferred phrasing than the developer reaction on X and HN.¹²

March was already the warning

The April 28 post follows a March 11 post in which GitHub said recent incidents were driven by rapid load growth, architectural coupling, and insufficient load shedding.¹⁴ GitHub’s March availability report then documented four March incidents, including a March 3 event where github.com request failures peaked around 40 percent, API request failures around 43 percent, HTTP Git operations around 6 percent, and Copilot around 21 percent.¹³

April is not a clean break from March. The pattern continues: high growth, tight coupling, shared dependencies, load amplification, and monitoring gaps that miss correctness failures inside critical workflows.

Final assessment

GitHub’s explanation is plausible but incomplete. Agentic development almost certainly increased load sharply on PRs, Actions, APIs, and automation. The growth numbers point in that direction even if the chart context is thin.

The incidents themselves point to internal engineering debt that capacity work alone will not fix:

• Feature flag gating that allows unreleased-feature code paths to apply to production workflows.²
• Test coverage that exercises single-PR cases but not the multi-PR squash path that broke.²
• Monitoring that does not validate merge correctness, leaving customer support inquiries as the detection mechanism for a 3 hour 33 minute correctness defect.²
• Shared dependency exposure, where Elasticsearch overload silently empties PR, issue, project, and Actions UI pages while underlying data remains intact.¹⁴¹¹
• Status page calculus that excludes Degraded Performance from downtime, shielding headline uptime numbers from incidents that actively block developer workflows.⁶

The most defensible read: GitHub’s April 2026 problem is workflow reliability, not uptime. The new status page makes that gap legible if you read it carefully. The April 28 post makes the case for capacity. It does not answer whether merge queue correctness, search-coupled UI, and feature flag hygiene are getting the same urgency as the 30X capacity plan.

Notes

1. 1. Vladimir Fedorov, "An Update on GitHub Availability," GitHub Blog, April 28, 2026.
2. 2. GitHub Status, "Incident with Pull Requests," April 23, 2026.
3. 3. GitHub Community, "[2026-04-23] Incident Thread," Discussion #193645, accessed April 28, 2026.
4. 4. GitHub Status, "GitHub Search Is Degraded," April 27, 2026.
5. 5. GitHub Status, "Incomplete Pull Request Results in Repositories," April 28, 2026.
6. 6. GitHub, "Bringing More Transparency to GitHub's Status Page," GitHub Blog, April 17, 2026.
7. 7. GitHub Status, "GitHub Status," accessed April 28, 2026.
8. 8. Kyle Daigle (@kdaigle), "Wanted to provide more clarity about this," X, April 24, 2026.
9. 9. Tom Elliott (@theotherelliott), "This GitHub incident is insane," X, April 24, 2026.
10. 10. Gergely Orosz (@GergelyOrosz), "Pull requests disappeared on GitHub for many (all?) users," X, April 27, 2026.
11. 11. Mario Rodriguez (@mariorod1), reply explaining GitHub pages and Elasticsearch-backed query results, X, April 28, 2026.
12. 12. Craig Risi, "GitHub Acknowledges Recent Outages, Cites Scaling Challenges and Architectural Weaknesses," InfoQ, April 2026.
13. 13. GitHub, "GitHub Availability Report: March 2026," GitHub Blog, April 2026.
14. 14. Vladimir Fedorov, "Addressing GitHub's Recent Availability Issues," GitHub Blog, March 11, 2026.
15. 15. Hacker News, "An Update on GitHub Availability," item 47932422, accessed April 28, 2026.
16. 16. GitHub Status API, incidents.json, summary.json, and components.json, captured April 28, 2026.