I’ve set up a cloud automation with a Github workflow trigger. Very simple, basically if this workflow failed, automatically investigate and report. But I had to give up on it because it is just NOT reliable at all. My test workflows with failures were not triggering. Eventually I turned off all criteria (any workflow, any conclusion) and… over a period of 2 hours, it triggered 5 times, despite 28 workflows running. Over the next 24 hours, only 10 triggers, despite lots of workflows. And it never triggered on the workflows I cared about.
I gave up and used the cursor webhook to force an agent to run (but this is ALSO unsatisfactory, other bug report).
No idea how to debug this; I can’t tell if the problem is GH delivery or Cursor wakeup.
This isn’t unreliable GitHub delivery on our side. Workflow run completed only starts a Cursor run when the Actions run itself was started by a push. Manual workflow_dispatch runs, schedules, and workflows that only run on pull_request can finish fine in GitHub and still never show up in Run History.
Quick check: open one of the runs you cared about in GitHub Actions and look at the Event field. If it’s workflow_dispatch or pull_request, that matches what we see - the runs that did fire for your automation lined up with push completions on main.
For CI-failure triage on PRs, CI completed is usually the better trigger. Alternatively, have the workflow(s) you care about also run on push to those branches. If you filter by workflow name, match the file name (e.g. deploy.yml), not the YAML display name:.
We’ve let the team know the docs/UI should spell this out more clearly - the Automations docs currently say the run finishes “on a pull request or branch,” which is easy to misread. Happy to dig into a specific workflow run’s Event field with you if you paste one.
The push-only limit is deliberate, not flaky delivery: a run started by a push identifies who actually wrote the code the agent would act on, so the “who can trigger a run” permission stays meaningful. Manual, scheduled, and release runs don’t carry that, so they’re excluded for now.
Totally agree broader triggers for agentic review would be useful - we’ll track this thread to gauge interest, so chime in if you want it. You’re also right the limit isn’t surfaced anywhere (hence the agents building it not knowing either), and that the yml route is a step down from the automation UI. We’ve let the team know the behavior should be spelled out in the UI and docs.