Some Merged Pull Requests Triggered Plan Workflows Instead of Apply | System Status

Summary

Between June 11 and June 12, 2026, some pull requests that were merged did not trigger an apply workflow as expected — they either triggered a plan workflow or showed no dispatch activity. This was caused by a disruption in GitHub's webhook delivery system that resulted in certain webhook events being delayed by minutes to hours. No customer data was lost or compromised, and no infrastructure changes were applied without authorization.

Impact

A subset of pull requests merged during the GitHub webhook delivery outage window dispatched a plan workflow instead of an apply workflow
Affected repositories received no notification that the expected apply had not been triggered
Pull requests closed or merged during the outage window were most at risk; the delay ranged from under a minute to approximately five hours in the most extreme cases observed
Repositories, workflow history, and running jobs were not affected — only the dispatch decision for the specific merge events processed during the outage window

Timeline

GitHub begins experiencing degraded webhook delivery — events are queued and delivered late rather than in real time

First affected merge events processed by Atmos Pro; late-arriving push notifications cause some merges to dispatch plan workflows instead of apply

Additional delayed webhook deliveries continue to arrive; most extreme observed delay is approximately 5 hours between merge and the late-arriving push notification

GitHub confirms resolution of the webhook delivery incident on their status page

Atmos Pro platform update deployed with a fix that prevents out-of-order webhook delivery from causing incorrect dispatch decisions in the future

What Happened

GitHub's webhook delivery system experienced an outage that caused certain event notifications to be delayed significantly — in some cases by several hours. During this window, the order in which Atmos Pro received GitHub events did not match the order in which those events actually occurred.

Atmos Pro determines whether to dispatch a plan or an apply workflow based on the most recent event it has recorded for a given pull request. Under normal conditions, the "merge" notification arrives last, so Atmos Pro correctly dispatches an apply. During the GitHub outage, earlier notifications about code pushes to a branch were delivered after the merge notification — sometimes hours later. When those stale events arrived, Atmos Pro updated its view of the pull request's last known state, replacing the merge context with a push context. Any subsequent dispatch decision for that pull request then incorrectly triggered a plan workflow instead of apply.

This was an ordering problem introduced entirely by GitHub's delayed delivery. The merge itself was recorded correctly; it was the late arrival of earlier push notifications that overwrote the event context Atmos Pro used to drive the dispatch.

What We Did

1
Identified that affected dispatch decisions correlated with GitHub's webhook delivery outage window
2
Confirmed via event timestamps that the incorrect dispatches were caused by late-arriving push notifications overwriting correct merge context — not a bug in normal workflow logic
3
Deployed a platform update that records each webhook event's original occurrence time (as reported by GitHub) alongside its delivery time, and uses occurrence order — not delivery order — to determine a pull request's current state

What We're Doing to Prevent This

Event ordering by occurrence time. We have updated Atmos Pro to track when each GitHub event actually happened, not just when it was delivered to us. The dispatch pipeline now determines a pull request's current state based on the sequence of events as they occurred on GitHub's side — so a late-arriving push notification can never overwrite a merge event that happened earlier, regardless of delivery delays.
Improved visibility into dispatch decisions. We are adding monitoring to surface cases where a merge event results in no apply dispatch, so our team and affected users can identify and act on these situations without waiting for a downstream failure to surface the gap.
Resilience against upstream delivery disruptions. We are hardening the webhook ingestion pipeline to be explicitly tolerant of out-of-order delivery from GitHub, so that future disruptions in GitHub's delivery infrastructure do not alter dispatch outcomes for events that have already been correctly processed.

Summary

Impact

A subset of pull requests merged during the GitHub webhook delivery outage window dispatched a plan workflow instead of an apply workflow

Affected repositories received no notification that the expected apply had not been triggered

Pull requests closed or merged during the outage window were most at risk; the delay ranged from under a minute to approximately five hours in the most extreme cases observed

Repositories, workflow history, and running jobs were not affected — only the dispatch decision for the specific merge events processed during the outage window

Timeline

GitHub begins experiencing degraded webhook delivery — events are queued and delivered late rather than in real time

First affected merge events processed by Atmos Pro; late-arriving push notifications cause some merges to dispatch plan workflows instead of apply

Additional delayed webhook deliveries continue to arrive; most extreme observed delay is approximately 5 hours between merge and the late-arriving push notification

GitHub confirms resolution of the webhook delivery incident on their status page

Atmos Pro platform update deployed with a fix that prevents out-of-order webhook delivery from causing incorrect dispatch decisions in the future

What Happened

What We Did

Identified that affected dispatch decisions correlated with GitHub's webhook delivery outage window

Confirmed via event timestamps that the incorrect dispatches were caused by late-arriving push notifications overwriting correct merge context — not a bug in normal workflow logic

Deployed a platform update that records each webhook event's original occurrence time (as reported by GitHub) alongside its delivery time, and uses occurrence order — not delivery order — to determine a pull request's current state

What We're Doing to Prevent This

Event ordering by occurrence time. We have updated Atmos Pro to track when each GitHub event actually happened, not just when it was delivered to us. The dispatch pipeline now determines a pull request's current state based on the sequence of events as they occurred on GitHub's side — so a late-arriving push notification can never overwrite a merge event that happened earlier, regardless of delivery delays.

Improved visibility into dispatch decisions. We are adding monitoring to surface cases where a merge event results in no apply dispatch, so our team and affected users can identify and act on these situations without waiting for a downstream failure to surface the gap.

Resilience against upstream delivery disruptions. We are hardening the webhook ingestion pipeline to be explicitly tolerant of out-of-order delivery from GitHub, so that future disruptions in GitHub's delivery infrastructure do not alter dispatch outcomes for events that have already been correctly processed.