Grok BotKnown issues

Illustration: a wall-mounted status panel with three round lamps, the center one dark, and a small paper ticket on the ledge below, in black and white.
Illustration

Status page: Grok Bot event routines failed for hours today

Event triggers dropped from 1:52 to 4:29 PM ET Oct 13. Staff say the same shared webhook limit filled again Oct 16; retry with backoff.

If a Grok Bot routine fired by webhook, Slack, git, email or Linear was due this afternoon, resend the event. Cursor's status page says that between 10:52 AM and 1:29 PM PT on October 13 (1:52 PM to 4:29 PM ET), many of those event-started routines didn't run, and "Events sent during this window weren't processed and won't be retried automatically, so please resend anything important."

  • Status: The Oct 13 incident is resolved. The shared limit filled again on Oct 15 and Oct 16, per staff (see Update below).
  • Window: 1:52 PM to 4:29 PM ET (10:52 AM to 1:29 PM PT).
  • Symptoms: Event triggers failed. Webhook callers may have seen HTTP 400 with "Automation run rate limit exceeded." Other triggers failed without an error.
  • Cause (per status): "Your own usage didn't cause this." The page names the "Automation run rate limit exceeded" error but gives no other cause.
  • Workaround: Resend the webhook, Slack message, git event, email or Linear signal yourself.

Update, Oct 16, 10:02 AM ET:#

The same webhook error came back this week. On Oct 15 a user reported HTTP 400 with "grok bot limit 18000 per minute," and Colin said it is "a shared limit across all Grok Bot routines on the platform." At 9:39 AM ET today another user got "Automation run rate limit exceeded: grok bot limit 20000 per minute, current_count=20001", so the limit now reads 20000 per minute, up from 18000.

At 10:02 AM ET Colin replied: "This is the same shared limit as yesterday. It isn’t tied to your account or how much you send, so nothing on your side is causing it. The extra room we added yesterday wasn’t enough for today’s traffic, and the team is working on a longer-term fix."

What he says to do:

  • "The webhook currently answers this with a 400 status, so many retry policies will treat it as permanent and give up."
  • "treat a 400 whose error says “Automation run rate limit exceeded” as temporary, and retry it with backoff (for example after 1, 2, 5 and 10 minutes). Calls do get through in between, so a retry a few minutes later usually lands."
  • It has shown up "roughly 12:00 to 17:00 UTC" (8:00 AM to 1:00 PM ET), "so that’s where retries matter most."
  • "Calls rejected with this error aren’t queued or run later, so anything that wasn’t retried will need to be resent."

Our advice: if your sender can't be changed to retry on a 400, keep a log of webhook calls that got this error so you know what to resend. Colin gave no date for the longer-term fix, and status.cursor.com showed All Systems Operational with no incident for it at about 10:17 AM ET.

What changed#

Earlier today staff confirmed a platform-wide automation start limit on the forum, and our drafts at 12:38 PM and 4:14 PM ET still showed "All Systems Operational" on status.cursor.com. At 5:13 PM ET Cursor posted a major incident titled "Grok Bot routines not triggering," already marked resolved and dated to 4:29 PM ET, when the window ended. That is the first status-page record of today's rate-limit window for Grok Bot event routines.

A user posted at about 4:42 PM ET that every POST to a Grok Bot webhook from about 2:00 PM to 4:05 PM ET was refused with HTTP 400 and a JSON error naming "Automation run rate limit exceeded: grok bot limit 10000 per minute," later raised to 15000, still full.

Why it matters#

Event routines are the ones that hand work between systems. If a webhook or Slack trigger dropped mid-afternoon, the Bot never saw the payload, and nothing in the run history will replay it for you.

How to use it#

  1. List every Grok Bot routine that uses a webhook, Slack, git, email or Linear trigger.
  2. For each one due between 1:52 PM and 4:29 PM ET, check whether a run exists for that event.
  3. Resend anything missing. For a webhook, POST the same payload again to the routine's webhook URL. For Slack or git, re-send the message or push. For email or Linear, re-deliver the message or update.
  4. If you also run Cursor Automations on PR, Slack or webhook triggers, check those Runs lists too. Staff earlier said those triggers are not retried when the shared start limit fills.

Example prompt for your Bot:

Check which of my webhook, Slack, git, email and Linear routines were due between 1:52 PM and 4:29 PM ET today. List any with no run in that window so I can resend the event.

Good to know#

  • This status note is about event-started Grok Bot routines. It does not name scheduled (cron) routines. The separate morning hold on scheduled routines that kevinn described at 3:36 PM ET is a different window.
  • Cursor Automations on PR, Slack and webhook triggers hit the same kind of platform start limit earlier today. Scheduled automations get a few automatic retries; event triggers do not.
  • kenners22 asked for queueing or retries on webhook triggers, and for HTTP 429 with Retry-After instead of 400. No staff reply on that ask yet.

What to watch#

The longer-term fix Colin mentioned (no date), whether Cursor adds retry or queueing for event triggers, and whether the morning scheduled-routine hold gets its own status entry.

Sources

  1. status.cursor.com
  2. stspg.io
  3. forum.cursor.com
  4. forum.cursor.com
  5. forum.cursor.com
  6. forum.cursor.com
  7. forum.cursor.com
  8. forum.cursor.com

Something wrong? Tell the bot