Summary
From September 7 through September 9, 2026, some pull requests that were merged did not trigger their post-merge workflows. The defect shipped in a platform update on September 6; the first merge it affected was at 04:58 UTC on September 7. The merge was recorded, the upload from your CI job reported success, and the pull request showed the affected stacks as received — but no apply (or post-merge plan) workflow was dispatched, and nothing told you. A customer noticed and reported it on September 8. We identified the cause on September 9, and the fix is deployed in the same release that publishes this report. Every affected merge is recorded and can be dispatched from the dashboard.
We are responsible for this. The defect was introduced by a change we shipped, and the fact that it was silent — for two days, across multiple customers — is the part we regret most.
Impact
- A merged pull request was affected when its final commit had already been planned within the previous 24 hours, which is the common case. For those merges, the post-merge affected-stacks upload was discarded and no workflows were dispatched.
- There was no error. The CLI printed a success message, the pull request comment and check showed the upload as received, and our own monitoring recorded nothing. The only visible symptom was the absence of a dispatch.
- Across all customers, 16 merges in 8 repositories across 6 workspaces were affected between 04:58 UTC on September 7 and the release of the fix. We are contacting each affected customer directly with the specific pull requests.
- The same de-duplication also discarded a second upload for a commit on an open pull request when the CI job was re-run within 24 hours — for example, re-running the job to refresh plans. Re-running the affected-stacks job after a merge produced the same result: the upload was discarded. In total, 34 of the 317 uploads received during the incident were discarded; the other 283 were processed normally.
- Merges whose final commit had not been planned in the prior 24 hours dispatched normally, as did plans on new pushes to open pull requests, drift detection, scheduled workflows, manually dispatched workflows, and the dashboard's re-trigger action.
- Every affected merge is recorded with its affected stacks and can be dispatched from the dashboard.
Timeline
A platform update is released that de-duplicates repeated upload requests from CI jobs. The defect ships with it.
First affected merge: a pull request merges, its upload is received and acknowledged, and no workflows are
dispatched.
A customer reports that merges have stopped triggering affected stacks and that they have been dispatching workflows
by hand.
Root cause identified. Every affected merge across all customers is identified from our records.
Fix complete and verified. It is deployed in the same release that publishes this report, which closes the incident.
What Happened
When your CI job uploads the list of affected stacks, it can occasionally time out waiting for our response and send the same upload again. On September 6 we shipped a change so that a repeated upload is recognized as a repeat and does not create a second round of workflows. To decide whether an upload was a repeat, the change compared the commit it referred to.
That was the mistake. A pull request's last pre-merge upload and its post-merge upload refer to the same commit — the merge simply lands that commit on your default branch. So when the post-merge upload arrived less than a day after the pre-merge one, our platform judged it a repeat of the upload it had already processed and discarded it. Because the discard happened after we had already acknowledged the upload as received, every signal you could see — the CLI, the pull request comment, the check — reported success.
One thing compounded this. Our acknowledgment to the CLI means "we received your upload," not "we have processed it" — processing happens asynchronously after the acknowledgment, so a discarded upload and a processed one were indistinguishable from the outside. And nothing in your workspace recorded that an upload had been received, so there was no trail showing an upload with no dispatch after it.
What We Did
- 1Reproduced the failure from a customer's merge and confirmed that the upload had reached us, been acknowledged, and then been discarded as a duplicate.
- 2Identified every affected merge across all customers from our records, so no one has to audit their own history to find out whether they were affected.
- 3Corrected the de-duplication so that a repeat is identified by the specific pull request event and the specific CI job run — a genuine retry of the same request still collapses into one, but a pre-merge upload and a post-merge upload can never be mistaken for each other.
- 4Every affected-stacks upload is now recorded in your workspace audit log, together with the pull request event it was matched to and the CI job it came from. Dispatches were already recorded there, so an upload that is not followed by a dispatch is now visible to you — not only to us.
- 5Began contacting each affected customer directly with the list of merges to re-dispatch.
What We're Doing to Prevent This
- An audit trail you can act on. Upload receipts now appear in the workspace audit log alongside dispatches, so the "received but nothing followed" pattern that defined this incident is visible in your own records, and is included in audit-log forwarding for teams that route it to their own monitoring.
- Never identify an event by its commit. A pull request's pre-merge and post-merge events share a commit by design. We have made it a review rule that anything which needs to tell events apart must use the event itself, and added a test that exercises exactly this pre-merge/post-merge pairing so a future change cannot reintroduce the collision.
- Verify dispatch outcomes after every release that touches the dispatch path. We now check, after deploying such a change, that merges continue to dispatch at the rate they did before — which would have caught this within hours rather than days.