We have a Cursor automation triggered by pushes to a PR, but we’re seeing it get rate limited. When this happens, the automation appears to fail silently and isn’t retried, meaning we have to intervene manually.
Is there a way to configure the automation to retry automatically when rate limited, or to queue the run until the rate limit clears, so that it eventually executes successfully without manual intervention? Any recommendations for handling this reliably would be appreciated.
Hey @Phil_Waters, thanks for the report!
The runs that failed today were blocked by a platform-wide limit on how many automation runs can start per minute across all customers, not by anything your team did. That limit was saturated for several hours today and has since cleared, so new pushes should be going through normally again.
To answer your question directly: there isn’t a setting yet to retry or queue a PR-triggered run when it hits this limit. Scheduled automations are retried automatically a few times when this happens, but PR, Slack and webhook triggers are not. I’ve passed your request for automatic retry or queuing on to the team.
In the meantime, here’s how to recover a run that was dropped:
git commit --allow-empty -m "Re-run automation"
git push
If the job could also run on a schedule (for example, a periodic pass over open PRs), scheduled runs do get those automatic retries, which can work as a backstop.
Same thing here on Grok Bot (Linux desktop 0.68.1), webhook-triggered routine, 13 Oct 2026. It started again after the 16:36 UTC note above.
Every POST to the routine’s webhook from about 18:00 to 20:05 UTC was refused with HTTP 400:
{"success":false,"error":"Automation run rate limit exceeded: grok bot limit 10000 per minute, current_count=10001"}
By 19:40 UTC the cap in the message changed to 15000 and it still filled up (current_count 15001–15003). A 15-minute retry loop with backoff (30 s up to 2 min) never got through. Our own usage is tiny (a handful of webhook calls a day), and Grok Bot / Automations showed “operational” on status.cursor.com the whole time.
Two asks:
Thanks!
Seeing this again today (14 Oct 2026) on Grok Bot, Linux desktop 0.70.2 (AUR grok-bot-bin), webhook-triggered routine called from a GitHub Action (one issue-labeled event per call).
Every POST is refused with HTTP 400:
`{“success”:false,“error”:“Automation run rate limit exceeded: grok bot limit 18000 per minute, current_count=18001”}`
Failed at 13:15:12, 13:16:42 and 13:21:51 UTC. The cap has gone up from yesterday’s 10000/15000 but it’s still saturated. status.cursor.com shows all systems operational and no incident today. Our usage is a few calls a day.
+1 to queuing or retrying webhook runs, and to returning 429 with Retry-After instead of 400.
victims of your own success ?!
Same error today, Oct 15, on Grok Bot (Linux desktop 0.71.2 on my hub, macOS 0.70.2 on my laptop), webhook-triggered routine.
My Claude Code agents hand tasks to Grok Bot through the routine’s webhook. A test round trip worked at 13:03 UTC. From about 14:05 UTC every POST came back HTTP 400:
{"success":false,"error":"Automation run rate limit exceeded: grok bot limit 18000 per minute, current_count=18001"}
I retried every 4 minutes through 14:32 UTC and nothing got through. The count sat at exactly 18001 the whole time, which looks stuck rather than busy. I’ve sent maybe ten calls today, and status.cursor.com showed all systems operational.
+1 to the asks above. A 429 with Retry-After, or a queue like scheduled runs get, would make webhooks usable for agent-to-agent handoffs. Is there an ETA on either?