[2026-04-23] Incident Thread

[github-actions[bot]]

❗ An incident has been declared:

Incident with Pull Requests

Subscribe to this Discussion for updates on this incident. Please upvote or emoji react instead of commenting +1 on the Discussion to avoid overwhelming the thread. Any account guidance specific to this incident will be shared in thread and on the Incident Status Page.

[github-actions[bot]]

Update

We have identified a regression in merge queue behavior present when squash merging or rebasing. We have identified the root-cause and are in the process of reverting the change.

[github-actions[bot]]

Update

We have resolved a regression present when using merge queue with either squash merges or rebases. If you use merge queue in this configuration, some pull requests may have been merged incorrectly between 2026-04-23 16:05-20:43 UTC.

This behavior is still present in GitHub Enterprise Cloud with Data Residency, and we are rolling out the same fix.

---

Relevant stamps: dotcom

[github-actions[bot]]

Incident Resolved

This incident has been resolved.

[andre-bonfatti]

We experienced ~20 pull requests which were flagged as merged through the queue but the weren't in fact merged. Now some commits are "popping" up on our commit history with a [restored] suffix. It seems a fix's still ongoing, but status page says all green? Would love clarity so we can prioritize fixes on our side.

[andre-bonfatti]

Since I posted this message we haven't seen any of the [restored] additions. From the ~20 PRs impacted, 4 self-healed.

[ross-imprint]

Same situation here - HEAD does not match the contents of the PRs that were merged today. Unclear if we need to resolve ourselves, or if Github is fixing - have not seen commits with [restored].

[andre-bonfatti]

We're resolving ourselves, I've not seen any additional restored commits in the past 25 minutes

[ross-imprint]

Can you post a screenshot of what [resolved] looked like for you? I may not be looking at the right place?

[andre-bonfatti]

@ross-imprint This is what it looks like, a [restored] text just after the PR number when viewing a commit

[github-actions[bot]]

Incident Summary

On April 23, 2026, between 16:05 UTC and 20:43 UTC, the Pull Requests service experienced a regression affecting merge queue operations. PRs merged via merge queue using the squash merge method produced incorrect merge commits when the merge group contained more than one PR. In affected cases, changes from previously merged PRs and prior commits were inadvertently reverted by subsequent merges.

During the impact window, 230 repositories and 2,092 pull requests were affected. The issue did not affect pull requests merged outside of merge queue, nor merge queue groups using the merge or rebase methods.
It took approximately 3 hours and 33 minutes to identify the issue. The change completed deployment at approximately 16:05 UTC, and we became aware at 19:38 UTC following an increase in customer support inquiries. Because the issue affected merge commit correctness rather than availability, it was not detected by existing automated monitoring and was identified through customer reports.

The regression was introduced by a new code path that adjusted merge base computation for merge queue ref updates. This code path was intended to be gated behind a feature flag for an unreleased feature, but the gating was incomplete.

As a result, the new behavior was inadvertently applied to squash merge groups, producing an incorrect three-way merge. This caused subsequent squash merges to revert changes from earlier pull requests and, in some cases, changes between their starting points.

We mitigated the incident by reverting the code change and force-deploying the fix across all environments. After resolution, we identified affected repositories and sent targeted remediation instructions to repository administrators with step-by-step recovery guidance.

The regression was not identified during internal validation. Existing test coverage primarily exercised single-PR merge queue groups, which did not exhibit the faulty base-reference calculation. Because automated checks did not validate merge correctness for multi-PR squash groups, the defect surfaced only in production.

To prevent recurrence, GitHub is expanding test coverage for merge correctness validation. We are broadening automated coverage for merge queue operations, including regression checks that validate resulting Git contents across supported configurations, so issues affecting merge correctness are caught before reaching production.

We are committed to ensuring the correctness and reliability of merge queue operations. These actions will reduce the risk of similar regressions and improve confidence in future changes to the Pull Requests service.