GitHub's Merge Queue Produced Wrong Code — The Uptime Story Masks the Worse Problem
The Data Integrity Failure
GitHub's merge queue ran squash merge against multi-PR groups and produced silently incorrect merge commits on 2,092 PRs around April 23, 2026. Modal and Zipline have confirmed they were hit. Main may now contain commits that do not match what reviewers actually approved. CI did not catch this, and CI was never going to. CI trusts the merge commit. It does not re-derive it.
Uptime you can route around. Wrong bytes you cannot.
The Uptime Crisis Underneath
GitHub's 90-day uptime is 85.51%. That is two to three hours of partial outage every day. CTO Vlad Fedorov points at AI agent load: 3.5x traffic growth in two years on infrastructure that took 15 years to build. One PR fans out to 12+ subsystems — Git storage, merge checks, branch protection, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, databases. Multiply PR creation by 3.5x and every one of those 12 systems gets 3.5x.
Why This Is GitHub-Specific
Vercel, Linear, Railway, Sentry, GitLab, and Bitbucket are eating comparable AI-driven growth without comparable degradation. Google's SRE org was planning for 10x code production by July 2025. GitHub started planning for 10x in October 2025, revised to 30x by February 2026. That is an architectural gap, not a calendar coincidence.
What Actually Holds Up in a Brownout
- Pin runner images and cache locally. Registry blips stop stalling cold starts.
- Move release artifacts off GitHub Packages into object storage you own.
- Keep a self-hosted runner pool sized for the critical path.
- Make deploy jobs idempotent so a retry after a 503 costs nothing.
uses: actions/checkout@v4is the line that proves the point. If the Actions control plane is down, nothing downstream of it runs, no matter where the code lives.
The Enterprise Server Angle
GitHub Enterprise Server is still exposed to a critical Wiz-disclosed RCE via git push (CVE-2026-3854) until you patch it by hand. Pair that with the Mini Shai-Hulud credential theft campaign and the chain writes itself: stolen developer tokens push malicious commits, malicious commits get RCE on the source control server.
What to do
Audit all commits merged via GitHub merge queue (squash merge) around April 23, 2026 — diff actual merged content against expected PR diffs
Implement a GitHub-independent deployment gate: mirror critical repos to a secondary remote and verify deploy pipeline can operate from the mirror
Patch GitHub Enterprise Server for CVE-2026-3854 (RCE via git push) immediately