Run the official checklist first

The official troubleshooting entry for a routine that did not run lists the things to verify before anything else. Most missed runs come down to one of these.

Four changes in Grok Bot 0.77.0 (October 26) touch this checklist. Approval cards raised by unattended work now stay open for 30 minutes instead of 10, in the app and in Slack, so a routine that needs you has three times as long before its action is dropped. Background work that hits a connector you were signed out of stops calling it and tells you to reconnect, instead of failing quietly; when background work needs one of your apps, the Bot asks with an allow card in the app, or Allow once and Skip in Slack. Slack routines that listen for messages now see images on the message that started them. And if your plan does not include routines, the Bot now names the plan that does, which is the quickest way to tell a missing feature from a broken one.

0.78.1 (October 27) adds three fixes worth knowing. Routines made in a new Bot's first chat now run in your time zone instead of UTC, so a routine that fired hours off from a brand-new Bot has a release-note explanation; check its schedule after updating. Clicking a webhook routine opens its details, including the webhook URL. And when a Shared Bot (formerly Team Bot) routine needs one of your connectors, it asks in the routine's Slack thread and tags you, so look for the ask there before assuming the run failed.

Documentation: Grok Bot changelog: 0.78.1 (routine time zone in a new Bot's first chat, webhook details, Team Bot routines ask in Slack, October 27) ↗ Official troubleshooting ↗ Grok Bot changelog 0.71.2 (October 14): routines ask for sign-in instead of quietly stopping ↗ Grok Bot changelog 0.75.2 (October 22): Reconnect cards, pause and resume, webhook key ↗

  • The routine is enabled, not just saved.
  • The schedule and time zone are what you intended.
  • The Bot that owns the routine still exists and was not deleted or recreated.
  • Every plugin the routine needs is still authenticated.
  • The computer can reach the source system the routine reads from; a stuck or unreachable computer silently skips scheduled work.
  • Usage or account access has not been paused; an exhausted allowance with on-demand disabled stops routines.
  • For an event-triggered routine, the source channel, repository, and matching rule are still valid.
  • Recent run history has been checked for a failure, including Automation run rate limit exceeded (see the hourly limits below).
  • A manual Test run is tried only with a safe input: the troubleshooting page, last updated October 22, notes Test run can perform real external actions, not a dry run.
  • The app is up to date: since 0.71.2 a routine that needs a site sign-in asks you in chat instead of quietly stopping, and since 0.75.2 a signed-out connector shows a Reconnect card in the chat.

Routine failures on October 8, 9, 13 and 19

From about 10 AM ET on October 8, scheduled routines across many accounts started late, were marked Failed, or never started, into October 9. Cursor staff said it happened during a period of very high demand, that nothing was wrong with people's Bots, settings or computers, and that direct messages to Bots were not affected. Routines briefly recovered that evening and were then held back again. The status page did not list it; staff said a resolved notice there that evening referred to a different issue.

Staff explained the odd patterns people saw. While one run is waiting, the routine's next scheduled slots are skipped rather than queued, so a five-minute routine showed gaps of one and a half to two hours. A run that looked early was the previous slot's run finally starting. A backup routine set a few minutes after the primary waits in the same queue, so it gives no protection. Missed runs are not replayed.

On October 13 a Cursor staff member posted the all-clear in the main thread: the October 8 problem had been resolved on October 9, routines had been held back again for a few hours on the morning of October 13 (US time), and they had been going through since about 16:00 UTC. Staff added that some routines may still start later than scheduled during busy periods, which Cursor is tracking. Afterwards one user reported a weekly routine due at 18:00 UTC that never fired and others starting 13 to 24 minutes late; staff asked anyone whose routine still fails outright to reply with its name and due time.

Event-triggered routines had their own failure the same day. Cursor's status page says that between 10:52 AM and 1:29 PM PT on October 13 (17:52 to 20:29 UTC) many routines started by webhooks, Slack, git, email and Linear events did not run. Webhook callers may have seen HTTP 400 with Automation run rate limit exceeded; other triggers failed silently. Cursor said users' own usage did not cause it, and that events sent in that window were not processed and will not be retried. The notice was posted after the incident ended.

Routines were delayed once more on October 19. Cursor's status page reported a Grok Bot degradation where routines may be delayed from 16:15 to 17:21 UTC, with a fix in place at 17:10. The notice did not say whether delayed runs were dropped, so check anything due in that hour.

Documentation: Forum: all Grok Bot routines failed to run (staff replies, October 8 to 13) ↗ Cursor status: Grok Bot routines not triggering, October 13 ↗ Cursor status: Grok Bot routines delayed, October 19 ↗ Forum: routines failing or running hours late since October 8 (staff reply) ↗ Forum: routines firing late, early or not at all on October 8 (staff reply) ↗ Forum: routines don't auto-run on schedule (staff explanation and September 16 fix) ↗

  1. Leave affected routines switched on; staff said pausing, resuming, editing the schedule, copying or recreating them does not help. If you did any of that while troubleshooting, check the routines you want are switched back on.
  2. For anything time-sensitive, message the Bot and ask it to run the routine now.
  3. Resend any webhook call, Slack message, email or other event that should have started a routine between 17:52 and 20:29 UTC on October 13.
  4. Avoid long troubleshooting sessions with your Bots during an incident; several users said it used much of their weekly usage.
  5. Check the forum's grok-bot tag as well as the status page: the October 8 incident never got a status entry, and the October 13 trigger notice appeared only after it was over.

The limits that look like bugs

Two documented numbers explain a lot of confusion. A Bot can own up to 50 routines, and only the 20 most recent run records are kept per routine. If you inspect history after a busy routine has run more than twenty times, earlier runs are simply gone. Keep your own log for anything you need to audit.

There are hourly run limits too. Cursor's routines help says your routines can run up to 300 times an hour in total and each routine up to 200 times an hour, figures the 0.75.5 release notes (October 23) describe as raised from 100 in total. A run past either limit fails with Automation run rate limit exceeded and is not retried, so rerun it with Test or resend the webhook call, and ask the Bot to narrow the trigger or widen the schedule if one routine keeps hitting the limit. The help page adds that some runs fail with the same error because of a limit shared by all Grok Bot routines, even when yours run less often; Cursor calls that a known issue and says it will update the article once it no longer affects routines.

A routine that seems to have done nothing may have left a draft. The 0.75.5 notes say emails and Slack messages you ask a Bot to send go out once Auto-review allows them, while sends on routine and other turns still wait as drafts. Check the Bot's drafts before assuming the run failed.

The docs also say Grok Bot may ask whether to keep routines running after a long period away and pause them if there is no response. People who set up a routine and then stop opening the app find it paused, not broken. Open the app periodically or expect that prompt.

Routine management still leans on desktop: the mobile guide says editing schedules and test runs require the desktop app, and Cursor's routines help puts Test on desktop only, while the phone shows each recent run as Running, Succeeded or Failed with the reason. The help adds behaviours that look like bugs: a new routine waits for its next scheduled time rather than running when it is created; schedules follow the time zone under Settings → General → Bot → Timezone, where Auto-detect follows the computer you are on; and an hourly schedule, a short interval or a Slack trigger on a busy channel can use a week of usage in a day; see the usage limit guide.

Two more catch unattended routines. Cursor's help and the official docs, checked October 29, say an approval raised by work that started without you, such as a routine, expires after about 30 minutes, and the action then does not run; keep routine steps inside your Allow automatically rules or expect to answer quickly. Since 0.75.2 an expired approval leaves a chat line naming what expired, and since 0.71.2 a routine that needs to sign in to a site asks you in chat at that step instead of quietly stopping. And a routine that runs commands on your own Mac or PC needs that computer connected: Cursor staff said in October that the desktop app pauses the local connection when the screen locks, the computer sleeps, or the Grok Bot window has not been the active window for about 10 minutes, and does not resume it on its own when a scheduled job starts. Click into the Grok Bot window a few minutes before such jobs.

A forum report traced this to its root cause: a Cursor staff member (Colin) explained on October 5 that it is a deliberate power-saving behavior in recent desktop versions, that the local helper only restarts once someone is back at the Mac (an unlock, or bringing the Grok Bot window forward), and that a Bot's own request for the machine from another device does not bring the helper back yet. The reporter's watchdog relaunched the app 25 times with the screen locked; the helper came back only twice. Later replies in the same thread describe the identical drop on Windows, and on Mac Studio and Mac mini machines deliberately run as always-on, unattended agent hosts with sleep and App Nap already disabled, so the fix is not a local power setting. There is no official workaround yet beyond keeping the Grok Bot window focused; if a routine depends on local execution, treat an always-locked or always-backgrounded machine as unreliable until Cursor ships the fix. On October 13 another Cursor staff member (deanrie) said they could not confirm that 0.70.2 fixes it and that there is still no setting to turn it off; staff called one user's alternative, running Tailscale on the machine so the Bot can reach it without the app, a valid workaround. Another user had their Bot bring the Grok Bot window forward after starting each job, which staff said amounts to the recommended workaround.

Grok Bot 0.71.2 (October 14) changed the surrounding behaviour without announcing an end to that pause: when your computer sleeps, Bots treat it as disconnected within two minutes and say so right away; after a Wi-Fi, VPN or other network change they can run tasks on it straight away; and if work is meant for one of your computers that is offline, the Bot tells you instead of running it on another computer without asking. In the forum, one user wrote on October 20 that the drops had stopped for them from a version just before 0.72.0 across three Windows PCs, and another had said on October 14 that 0.70.2 fixed it on a Mac mini. Update first, then keep the window-focus workaround for any routine that cannot afford a miss.

Documentation: Skills and routines ↗ Settings: Bot timezone ↗ Cursor help: routines ↗ Cursor help: how-tos (approval expiry) ↗ Grok Bot changelog 0.71.2 (October 14): routines ask for sign-in instead of quietly stopping ↗ Grok Bot changelog 0.75.2 (October 22): Reconnect cards, pause and resume, webhook key ↗ Grok Bot changelog 0.75.5 (October 23): run limits raised, routine sends wait as drafts ↗ Forum: Mac mini local computer drops while idle (user reports through October 24) ↗ Forum: Mac shows disconnected until the app is focused (staff reply, October 9) ↗ Forum: Bot thinks my computer is offline or sleeping (staff reply, October 10) ↗ Forum: macOS local-exec daemon gets SIGTERM on an unattended, locked Mac (staff explanation, 310 views) ↗

Schedules that never fire

The main forum thread on routines that do not auto-run, opened September 2 and now past 20 replies, turned out to be server-side problems rather than user error. Cursor staff said the reporter's routines had fired at every slot but sat in a queue, starting 10 to 37 minutes late, and some runs finished without posting anything to the chat, so it looked as if nothing ran. Staff also said the platform a routine was created on, and edits to the Bot's instructions, do not affect its schedule.

On September 16 staff said a change rolled out the previous evening (UTC) gives each routine a reserved slot a few minutes out, so the silent skips should stop, although runs can still start a few minutes late at the busiest hours. On September 24 staff said they had added capacity and routines were starting within a few minutes of schedule, against 20 to 40 minutes during US mornings earlier that week; users kept reporting late or missed one-off runs afterwards. Separately, schedule edits or switch-offs made between September 4 and 8 could keep running on the old settings; staff asked people to re-save any routine that still looks wrong. Cursor's status page also recorded dropped routine trigger fires on September 3 to 4, and routines due during the October 3 incident did not run; Is Grok Bot down? lists every incident with its times.

Documentation: Forum: routines don't auto-run on schedule (staff explanation and September 16 fix) ↗ Cursor status: degraded routine triggers, September 3 to 4 ↗ Official troubleshooting ↗ Grok Bot changelog (routine summary on save, 0.69.0 to 0.70.2) ↗

  1. Open the routine and confirm enabled, schedule, and time zone. Since the October 11 release (0.69.0 to 0.70.2), the Bot sums up what a routine does and who receives the result when you save it, and each run delivers there; read that summary to confirm the routine posts where you expect.
  2. Check recent run history for a late start or a run that finished without posting; have the routine always post a one-line result so a quiet run is visible.
  3. Re-save the routine if its schedule or on/off state was changed in early September.
  4. Run it once manually with a harmless input and watch the computer view.
  5. If a run still starts more than about 15 minutes late, report the routine name, scheduled time, and actual start time in the forum thread, as staff requested.

Webhook routines with no POST URL

Event routines can be triggered by integrations such as Slack messages or GitHub notifications, and by a webhook. A 29-reply thread began with the Windows 0.47.0 desktop app showing no POST URL and no key for a webhook routine, so nothing external could call it. Cursor staff confirmed it affected Mac and mobile too: newer Bots keep their routines on the server, and the apps were not fetching the webhook fields. Staff said the fix shipped in Grok Bot 0.53.0 for Windows, Mac, and Linux on September 16.

Update the desktop app, click the Bot's name, find Routines on the Details tab, and open the webhook routine; Cursor's help says its Webhook section shows POST to (the URL), key, and header (the full Authorization: Bearer header), each copied with a click. The mobile app does not show them. A 200 response means Grok Bot accepted the call and started a run, not that the Bot finished; any other response means no run started, so check the routine is not paused and the key is current. Do not try to guess a URL, and keep the key out of chat and shared templates.

Not everyone sees those fields. In a 450-view forum thread about the redesigned desktop Details pane, where Cursor staff said on October 9 that the simpler pane was an intentional redesign, one user reported on October 11 that each routine showed only its name, schedule and switch, with no saved prompt or webhook details. Cursor's routines help still describes the Instruction and Webhook fields. If they are missing for you, update the app and add your version to that thread rather than recreating the routine. The 0.75.2 release notes (October 22) say a webhook routine's menu now shows its URL and key, with the key hidden until you reveal it, and Cursor's routines help, rechecked October 25, still lists the Webhook section.

Documentation: Forum: unable to see or edit Bot instructions on desktop (staff reply, October 9; routine details reported missing October 11) ↗ Forum: webhook routine shows no POST URL (fixed in desktop 0.53.0) ↗ Skills and routines ↗ Cursor help: routines ↗ Grok Bot changelog 0.75.2 (October 22): Reconnect cards, pause and resume, webhook key ↗

Write routines that fail loudly

The official guidance recommends a no-data and stale-data policy for every routine: say what should happen when a source is missing. The example is 'If the source data is unavailable, report the failure instead of using old data.' A routine that reports a failure is one you notice; a routine that quietly reuses yesterday's numbers is one you discover weeks later.

Documentation: Skills and routines ↗

Try this brief

Every weekday at 8:00 AM in my time zone, open the attached tracker and produce a five-line summary of changes since the last run. If the tracker is unreachable, empty, or unchanged, send a one-line message saying so and do not reuse a previous summary. Do not edit the tracker. Return the summary for my review.

Original editorial template. Replace placeholders and review access before running.

Quick answers

Which versions fixed routines that stopped quietly?

Going by the release notes: since 0.71.2 (October 14), a routine that needs to sign in to a site asks you in chat at that step instead of quietly stopping. Since 0.75.2 (October 22), a routine that hits a signed-out connector shows that connector's Reconnect card in the chat, at most once a day; pausing and resuming keeps your last choice even when you tap from two devices; a routine's result still reaches you if you send a message before the Bot finishes handing it off; and an approval you don't answer in time leaves a chat line naming what expired. 0.75.5 (October 23) raised the hourly run limits. 0.78.1 (October 27) fixes two more: routines made in a new Bot's first chat run in your time zone instead of UTC, and clicking a webhook routine opens its details, including the webhook URL. Update the app first, then check the routine.

Why did my routines fail or run hours late on October 8 or 13?

A problem on Cursor's side both times. Staff said that from about 10 AM ET on October 8, during very high demand, scheduled routines were held back, started late or were marked Failed, while messaging Bots directly kept working; that was resolved on October 9. On the morning of October 13 (US time) routines were held back again for a few hours, and staff said they had been going through since about 16:00 UTC. Missed runs are not replayed, so ask the Bot to run urgent ones by hand, and check that any routine you paused or recreated while troubleshooting is switched back on.

My routine failed with Automation run rate limit exceeded. Did I do something wrong?

Possibly not. Cursor's routines help, rechecked October 25, says routines have hourly limits: your routines can run up to 300 times an hour in total and each routine up to 200 times an hour (0.75.5 raised the total from 100), and a run past either limit fails with that error. The same page says some runs also fail with it because of a limit all Grok Bot routines share, even when yours run less often; Cursor calls that a known issue its engineers are fixing. On October 13 between 10:52 AM and 1:29 PM PT (17:52 to 20:29 UTC) many event-triggered routines failed this way and your own usage did not cause it. Failed runs are not retried automatically, so rerun the routine with Test or send the webhook call again.

How many routines can a Bot have?

The official docs say a Bot can own up to 50 routines, and the app keeps the 20 most recent run records for each routine. Older runs disappear from history, which can look like the routine never ran.

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 there is no response. If you have been away from the app, open it and answer that prompt before assuming a bug.

My webhook routine shows no POST URL. Is that normal?

It was a known bug, not a configuration mistake, and it is fixed on desktop. Cursor staff said newer Bots keep routines on the server and the apps were not showing the webhook URL, key, or Authorization header on any platform; recreating the routine did not help. On September 16 staff said Grok Bot 0.53.0 fixed it on Windows, Mac, and Linux. Update the desktop app and open the webhook routine from the Bot's Routines list. The mobile app does not show these fields yet, so copy them from desktop.

Bots for this job

Directory listings that match this guide, read from each creator's public share page. They are not tested picks: check what a Bot can reach before you add it.

Browse: Bots for scheduled routines

  • Rutin by Naoufal El hassnaoui: A Monday tune-up for every routine across your fleet of bots
  • Fleet Keeper by TheCoderBTW: Keeps a Grok Bot fleet tidy: inventories bots and channels read-only, flags duplicates, overlaps, stale and unsectioned bots
  • Daili by ℙ𝕒𝕦𝕝 𝕃. 𝕄𝕔ℕ𝕖𝕖𝕝𝕪 🇺🇸: Morning briefs with calendar, weather, important mail, live connectors, and a weekly outlook
  • Competitor Watching by Andrej Šimunaj: Snapshots you against 3-8 competitors and alerts only on material change

Sources & next steps

Capabilities are grounded in the documentation below. The workflow design and acceptance checks are editorial suggestions.

Build your own workflow brief →