Skip to content
TheBestSuperintelligence

Fix problems

Grok Bot routine didn't run? Work through these causes in order

By Tal Slavin · Last checked · Next review 2026-11-06

◈ Executive SummaryCited · Documentation

Grok Bot routine didn't run? Work through these causes in order

Why a Grok Bot routine skipped, ran late or failed: the October 2026 incidents, hourly run limits, approval expiry, sleeping computers and webhook fixes.

◈Key Takeaways (5)
  • •Check status first: routines failed on Cursor's side on October 8, 9, 13 and 19, and missed runs are not replayed.
  • •Your routines can run up to 300 times an hour in total and 200 per routine; extra runs fail without retry.
  • •Approvals raised by unattended work expire after about 30 minutes, and the action then does not run.
  • •Routines that use your own Mac or PC need the Grok Bot window active; locked or backgrounded machines drop.
  • •Test run performs real external actions, so only test with a harmless input.
☰On this page (10 sections)
  1. 01.At a glance
  2. 02.Step 1: Rule out a platform incident
  3. 03.Step 2: Run the official checklist
  4. 04.Step 3: Check the limits that look like bugs
  5. 05.Step 4: Fix routines that depend on your own computer
  6. 06.Step 5: Schedules that never fire, and webhooks
  7. 07.Write routines that fail loudly
  8. 08.Our take
  9. 09.Frequently asked questions
  10. 10.Sources & Further Reading

A Grok Bot routine that did not run is usually one of five things: an incident on Cursor's side, an hourly run limit, an approval nobody answered, a computer that was asleep, or a routine that is paused or misconfigured. Rule out the platform first, because during an incident nothing you change will help. Then work through the checks below in order.

At a glance#

Symptom Most likely cause First move
Many routines failed or ran late at once Platform incident Check status and the forum; leave routines switched on
"Automation run rate limit exceeded" Hourly run cap, or the shared-limit known issue Rerun with Test or resend the webhook
Run started but did nothing Expired approval, a draft waiting, or a sign-in prompt Check chat for an expired-approval line and the Bot's drafts
Routine using your Mac or PC failed Local connection paused while locked or backgrounded Bring the Grok Bot window forward before the job
Fires hours off schedule Time zone; new-Bot routines used UTC before 0.78.1 Update and recheck the schedule
Routine paused by itself You were away; Grok Bot asked and got no reply Open the app and answer the prompt
Older runs missing from history Only 20 records kept per routine Keep your own log
Webhook routine has no URL Pre-0.53.0 bug or a hidden Details field Update the desktop app

Step 1: Rule out a platform incident#

Routines have failed on Cursor's side several times. While one run waits, the routine's next slots are skipped rather than queued, and missed runs are not replayed.

Date What happened
September 3 to 4 Status page: degraded routine triggers; some trigger fires may have been dropped
October 3 Routines due between about 2:00 and 3:10 AM ET did not run
October 8 to 9 From about 10 AM ET, scheduled routines were held back, ran late or marked Failed; no status entry
October 13, morning US time Held back again for a few hours; flowing from about 16:00 UTC
October 13, 17:52 to 20:29 UTC Many webhook, Slack, git, email and Linear triggered routines did not run; events will not be retried
October 19, 16:15 to 17:21 UTC Routines delayed; notice did not say whether runs were dropped

During the October 8 incident, staff said pausing, editing, copying or recreating routines does not help. A backup routine scheduled a few minutes after the primary waits in the same queue, so it gives no protection. A run that looked early was the previous slot's run finally starting.

During an incident#

  1. Leave affected routines switched on.
  2. Ask the Bot directly to run anything time-sensitive; direct messages kept working on October 8.
  3. Resend any event that should have triggered a routine between 17:52 and 20:29 UTC on October 13.
  4. Skip long debugging sessions with your Bots. Several users burned much of their week that way; see usage limits.
  5. Watch the forum's grok-bot tag too. The October 8 incident never got a status entry.
  6. Afterwards, confirm any routine you paused or recreated is switched back on.

Step 2: Run the official checklist#

The troubleshooting page, last updated October 22, lists what to verify. Most missed runs fall into one of these:

  • The routine is enabled, not just saved.
  • The schedule and time zone are what you meant. Schedules follow Settings → General → Bot → Timezone; Auto-detect follows the computer you are on.
  • The owning Bot still exists and was not deleted or recreated.
  • Every plugin the routine needs is still authenticated.
  • The computer can reach the source; a stuck computer silently skips scheduled work.
  • Usage is not exhausted with on-demand off.
  • For event routines, the channel, repository and matching rule are still valid.
  • Run history shows no failure such as Automation run rate limit exceeded.
  • The app is current. Since 0.71.2 a routine that needs a site sign-in asks in chat instead of stopping quietly; since 0.75.2 a signed-out connector shows a Reconnect card.

A new routine waits for its next scheduled time; it does not run on creation. Test run performs real external actions, not a dry run, so test only with a harmless input.

Step 3: Check the limits that look like bugs#

  • 50 routines per Bot, 20 run records per routine. After twenty runs, older history is simply gone.
  • Hourly caps. 300 runs an hour across your routines and 200 per routine since 0.75.5 (October 23). Runs past either fail and are not retried. Ask the Bot to narrow the trigger or widen the schedule.
  • Shared-limit known issue. Cursor's routines help says some runs fail with the same error because of a limit all Grok Bot routines share, even when yours run rarely.
  • Drafts, not sends. Since 0.75.5, emails and Slack messages from routine turns wait as drafts. Check drafts before calling a run failed.
  • Approval expiry. Approvals from unattended work stay open 30 minutes since 0.77.0 (up from 10), in the app and Slack. Then the action is dropped; since 0.75.2 a chat line names what expired. Keep routine steps inside your Allow automatically rules.
  • Shared Bot connector asks. Since 0.78.1, a Shared Bot routine that needs one of your connectors asks in the routine's Slack thread and tags you. Look there first.
  • Auto-pause. After a long absence Grok Bot may ask whether to keep routines running, and pause them if you do not answer.

Step 4: Fix routines that depend on your own computer#

A routine that runs commands on your Mac or PC needs that machine connected. Cursor staff explained on October 5 that the desktop app pauses its local helper when the screen locks, the computer sleeps, or the Grok Bot window has not been active for about 10 minutes. It only restarts when someone unlocks or brings the window forward.

Disabling sleep and App Nap does not help; users on always-on Mac minis and Mac Studios saw the same drop, and so did Windows users. One user's watchdog relaunched the app 25 times on a locked screen and the helper returned twice.

Symptom → Fix

  • Local job fails on schedule → Click into the Grok Bot window a few minutes before the job.
  • Unattended host you cannot babysit → Staff called running Tailscale on the machine, so the Bot can reach it without the app, a valid workaround.
  • Bot should keep itself connected → One user had the Bot bring the Grok Bot window forward after each job, which staff said amounts to the recommended workaround.
  • Still dropping → Update first. Users reported the drops stopped on 0.70.2 (a Mac mini) and on a build just before 0.72.0 (three Windows PCs), but Cursor has not said the pause was removed.

Since 0.71.2, a sleeping computer counts as disconnected within two minutes and the Bot says so, and work meant for an offline computer is not silently moved to another.

Step 5: Schedules that never fire, and webhooks#

The main forum thread on routines that do not auto-run turned out to be server-side. Runs had fired but queued, starting 10 to 37 minutes late, and some finished without posting. On September 16 staff said each routine now gets a reserved slot; on September 24 they said starts were within a few minutes, against 20 to 40 minutes on earlier US mornings. Schedule edits made between September 4 and 8 could keep old settings, so re-save any routine that still looks wrong.

  1. Open the routine and confirm enabled, schedule and time zone. Since the October 11 release, the Bot summarizes what a routine does and who gets the result when you save it.
  2. Check run history for a late start or a run that posted nothing.
  3. Run it once with a harmless input and watch the computer view.
  4. If it still starts more than about 15 minutes late, post the routine name, scheduled time and actual start time in the forum thread, as staff asked.

For webhook routines, update the desktop app, click the Bot's name, find Routines on the Details tab and open the routine. Its Webhook section shows POST to, the key and the full Authorization: Bearer header. A 200 response means a run started, not that it finished; anything else means no run started.

Keep the key out of chat and templates. If Details shows only name, schedule and switch, update and report your version in the forum rather than recreating the routine.

Write routines that fail loudly#

The docs recommend every routine state a no-data and stale-data policy. A routine that reports "source unavailable" gets fixed today; one that quietly reuses yesterday's numbers gets discovered next month. Make it post a one-line result every run so a silent run is visible. Our workflow brief guide and skills vs routines go deeper.

Every [weekday] at [time] in my time zone, read [source] and post a [N]-line

summary of what changed since the last run to [destination].

Always post a result, even if it is one line.

If the source is unreachable, empty or unchanged, say exactly that in one line

and do not reuse any earlier summary.

Do not edit [source]. Do not send anything externally; leave it as a draft.

Our take#

Assume a missed run is Cursor's problem until the status page and forum say otherwise, then walk the checklist. Build every routine to post something on every run, keep it inside auto-allow rules, and never trust a routine on a locked local machine with anything you cannot afford to miss. Our troubleshooting matrix covers the neighbouring failures.

Frequently asked questions#

Why did my Grok Bot routines fail on October 8 or 13?#

Both were problems on Cursor's side. From about 10 AM ET on October 8, scheduled routines were held back, ran late or were marked Failed into October 9. On the morning of October 13 (US time) they were held back again for a few hours, and event-triggered routines failed from 17:52 to 20:29 UTC. Missed runs were not replayed, so run urgent ones by hand.

What does Automation run rate limit exceeded mean?#

Your routines hit an hourly cap: up to 300 runs an hour in total and 200 per routine, per Cursor's routines help (0.75.5 raised the total from 100). Cursor also lists a known issue where a limit shared by all Grok Bot routines triggers the same error. Failed runs are not retried, so rerun with Test or resend the webhook call.

How many routines can one Grok Bot have?#

The official docs say a Bot can own up to 50 routines, and only the 20 most recent run records are kept per routine. Older runs vanish from history, which can make an active routine look like it never ran. Keep your own log for anything you need to audit.

Why did my routines pause on their own?#

The docs say Grok Bot may ask whether to keep routines running after a long period away, and pause them if nobody answers. If you set up routines and then stopped opening the app, open it and respond to that prompt before assuming something is broken.

Where is my webhook routine's POST URL?#

On desktop, open the Bot's Details tab, find Routines and open the webhook routine; its Webhook section shows the URL, key and Authorization header. A bug that hid these was fixed in 0.53.0 on September 16, and since 0.78.1 clicking a webhook routine opens its details. The mobile app does not show these fields.

Sources & Further Reading#

  1. Grok Bot docs: troubleshooting
  2. Grok Bot docs: skills, routines and automations
  3. Grok Bot docs: settings (Bot time zone)
  4. Cursor help: routines
  5. Cursor help: how-tos (approval expiry)
  6. Grok Bot changelog
  7. Grok Bot changelog 0.71.2 (October 14)
  8. Grok Bot changelog 0.75.2 (October 22)
  9. Grok Bot changelog 0.75.5 (October 23)
  10. Grok Bot changelog 0.78.1 (October 27)
  11. Status: Grok Bot routines not triggering, October 13
  12. Status: Grok Bot routines delayed, October 19
  13. Status: degraded routine triggers, September 3 to 4
  14. Cursor forum: all Grok Bot routines failed to run (October 8 to 13)
  15. Cursor forum: routines don't auto-run on schedule
  16. Cursor forum: webhook routine shows no POST URL
  17. Cursor forum: macOS local-exec daemon stopped on a locked Mac
  18. Cursor forum: Mac mini local computer drops while idle