# GitHub PR triggering automation rate limit **URL:** \ **Category:** Help\ **Tags:** github, automations\ **Created:** [October 13, 2026, 4:12pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611 "2026-10-13T16:12:24Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Phil\_Waters](https://avatars.discourse-cdn.com/v4/letter/p/3be4f8/32.png) [@Phil\_Waters](https://forum.cursor.com/u/Phil_Waters)\ **Post date:** [October 13, 2026, 4:12pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/1 "2026-10-13T16:12:24Z")
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. ---
**Author:** ![kevinn](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kevinn/32/101206_2.png) [@kevinn](https://forum.cursor.com/u/kevinn)\ **Post date:** [October 13, 2026, 4:36pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/7 "2026-10-13T16:36:44Z")
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: 1. Open the automation in the dashboard and check its Runs list. Blocked runs show up as failed with a “rate-limited due to too many concurrent runs” message, so you can spot which PRs were missed. 2. Push a new commit to each affected PR to fire the trigger again. An empty commit works: ```auto 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. ---
**Author:** ![kenners22](https://avatars.discourse-cdn.com/v4/letter/k/ee59a6/32.png) [@kenners22](https://forum.cursor.com/u/kenners22)\ **Post date:** [October 13, 2026, 8:42pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/8 "2026-10-13T20:42:37Z")
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](http://status.cursor.com) the whole time. Two asks: 1. Queue or retry webhook-triggered runs when this platform limit is hit, the same way scheduled runs are retried. A 400 that drops the run makes webhooks unreliable for agent-to-agent handoffs. 2. Return 429 with a Retry-After header instead of 400, so callers can tell “try again later” apart from a bad request. Thanks! ---
**Author:** ![komasoftware](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/komasoftware/32/121271_2.png) [@komasoftware](https://forum.cursor.com/u/komasoftware)\ **Post date:** [October 14, 2026, 1:23pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/9 "2026-10-14T13:23:28Z")
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](http://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. ---
**Author:** ![komasoftware](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/komasoftware/32/121271_2.png) [@komasoftware](https://forum.cursor.com/u/komasoftware)\ **Post date:** [October 14, 2026, 1:25pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/10 "2026-10-14T13:25:27Z")
victims of your own success ?! ---
**Author:** ![Michael\_Isaac](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/michael_isaac/32/123602_2.png) [@Michael\_Isaac](https://forum.cursor.com/u/Michael_Isaac)\ **Post date:** [October 15, 2026, 2:53pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/11 "2026-10-15T14:53:16Z")
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](http://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? ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [October 17, 2026, 2:53pm UTC](https://forum.cursor.com/t/github-pr-triggering-automation-rate-limit/174611/12 "2026-10-17T14:53:45Z")
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.