A GitHub automation with a Checks completed trigger does not fire at all.
The automation is active, the repository is selected, and the trigger is configured as:
Checks completed
On Failure
On PRs
by Anyone
Including Failures on Main
After pushing a new commit to an open PR, GitHub Actions fails, but the automation never starts. The automation Run History remains empty: 0 successful runs and 0 failed runs.
Prior thread’s context:
Steps to Reproduce
Create an automation on private personal repo
Configure the trigger as Checks completed / On Failure / On PRs / by Anyone / Including Failures on Main
Push a new commit to an open PR authored by the same GitHub user.
Wait for GitHub Actions and Cursor Bugbot checks to complete successfully.
Hey, thanks for moving this into a separate thread. I can see the screenshot for PR #334: branch cursor/improve-notification-copy-21fd into main, “All checks have failed”, iOS CI is failing. So the checks really did fail, and your trigger is “On Failure”, so it should’ve fired. The “by Me” bug from the previous thread isn’t related here since you’re on “by Anyone” and it’s a personal repo.
One thing stands out: the branch name cursor/... looks like the PR was created or pushed by the Cursor cloud agent. There’s a known limitation where the “Checks completed” trigger silently doesn’t fire for PRs created or pushed by the Cursor agent. In that case the checks come in under the cursor[bot] actor, and the trigger skips them. This looks like your case.
To confirm and tie it to the investigation, can you share:
the automation UUID plus a link to the repo and the PR
the approximate time the checks failed, with timezone
confirmation: were the commits to this PR pushed by the Cursor agent, or did you push them manually?
Quick test to validate the theory: push a commit to the same PR manually from your GitHub account so the new CI run starts from a human actor, then check if a Run History entry appears. If it fires on a human push but not on an agent push, that’s exactly the limitation I mean.
This is a bug on our side and it’s already tracked internally. I can’t share an ETA yet, but I’ll post an update here when I have one.
