The Silent Merge Queue Corruption That Hit 658 GitHub Repos — GitHub incident case study — Failure Modes<br>Skip to content<br>FM-029 GitHub2026-04-23impact 4h38m SEV-1<br>A silent merge queue bug corrupted 658 GitHub repos<br>GitHub's merge queue is supposed to protect the default branch. An incomplete feature-flag gate let an unreleased merge-base path run inside squash merge groups, producing valid-looking commits that silently reverted prior work while availability monitoring stayed green.<br>merge-queuefeature-flagsquash-mergegit-correctnesssilent-failure<br>summary#The merge queue's job is to protect the last dangerous step before code reaches the default branch. It takes pull requests that have passed review and CI, groups them, retests the combined state, and lands them in order. That contract depends on one quiet guarantee: the commit the queue writes must contain exactly what was validated. If the queue produces a commit that looks valid but has the wrong tree, the protection mechanism becomes the thing corrupting main.

On April 23, 2026, GitHub deployed a change to its Pull Requests service. The change introduced a new code path for merge-base computation during merge queue ref updates. It was supposed to stay dormant behind a feature flag for an unreleased feature, but the gate was incomplete. In the specific case of merge queue groups using the squash method with more than one pull request, the new path ran anyway.

That mattered because squash merge groups depend on choosing the right base for the final three-way merge. With the wrong base, GitHub could create a commit that appeared to advance the default branch while quietly dropping changes that had already been merged into the group. The Git history still existed. The commit object was structurally valid. The damage was semantic: the branch tip no longer represented the code the queue was supposed to land.

For 3.5 hours, the failure stayed invisible to GitHub's automated monitoring. Request rates, latencies, and errors did not describe the problem, because the service was still operating. It was just writing the wrong result for one configuration: multi-PR merge queue groups using squash. Single-PR groups, ordinary merges, rebases, and pull requests merged outside merge queue were not affected.

The first useful signal came from customers. Users noticed that pull requests showed as merged even though the expected changes were missing from HEAD, and some saw restored commits appear while the public status page looked healthy. GitHub became aware at 19:38 UTC after an increase in support inquiries, then traced the issue back to the incomplete feature-flag gate.

GitHub reverted the code change and force-deployed the fix by 20:43 UTC. The final impact was 658 repositories and 2,092 pull requests. No commits were lost, but affected default branches were wrong, and GitHub could not safely repair every repository automatically. After resolution, it identified affected repositories and sent targeted remediation instructions to repository administrators.

The lasting failure mode is the partial gate. A feature flag can create a false sense of containment when it guards the common paths but misses one variant combination. Here, the missed combination was exactly where correctness mattered most: the automated system trusted to serialize merges silently produced commits that undid earlier work, while the availability dashboard had no reason to turn red.<br>Automated checks did not validate merge correctness for multi-PR squash groups.// GitHub, Merge Queue Availability, April 2026

timeline · UTC#From the first signal to all-clear in 4h38m.<br>16:05 UTC

Deployment with incomplete flag gating completes<br>A code change adjusting merge base computation for merge queue ref updates is deployed. The new code path was intended to be gated behind a feature flag for an unreleased feature, but the gating logic was incomplete for the squash merge case.

16:05–19:38 UTC

Merge queue silently corrupts squash commits<br>For over three hours, any merge queue group containing multiple pull requests using the squash merge method produces an incorrect three-way merge, reverting changes from previously merged PRs. No automated monitoring detects the correctness failure.

19:38 UTC

GitHub becomes aware via customer support<br>Users reporting unexpected commit contents prompt support inquiries that surface the incident. GitHub has no automated signal for merge correctness — the issue exists for 3.5 hours before a human notices.

~20:30 UTC

Root cause identified: incomplete flag gate<br>Engineers identify the new merge base computation code path as the cause and confirm it escaped its feature flag gating for squash merge groups.

20:43 UTC

Resolved via code reversion and force deployment<br>GitHub reverts the deployment and force-deploys the previous version. The merge queue returns to producing correct commits.

root cause#An unreleased code path escaped its feature flag.<br>The merge queue service...