Grok Bot routines don't auto-run on schedule

[o_Oaii (OAiii)]

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Platform: iOS app (monitoring); affected bot originally created on Windows 11 desktop app, instructions edited via desktop multiple times since.

Summary:
Multiple scheduled routines on one Grok Bot fail to auto-execute at their set time. This has happened repeatedly across several days, including after deleting and recreating the routines. A separate routine on a different bot (same account) runs normally every day without issue. Two possible contributing factors are described below (routine creation platform, and frequency of instruction edits) — neither is confirmed as the root cause.

Expected behavior:
Routine should start automatically at the scheduled time (e.g., 11:00 KST, 21:00 KST) without requiring the user to open the app or send a manual message.

Actual behavior (timeline):
Early on, when the bot’s routines were first set up and checked via the Windows desktop app, the routine notification/alert did fire correctly 1-2 times.
The bot’s instructions (system prompt) were then edited multiple times over subsequent days, mostly via the desktop app.
Tue (Sep 1) 11:00 routine — did not start at scheduled time. No notification. Manual chat command sent to trigger it.
Tue (Sep 1) 21:00 routine — same failure. No auto-start, no notification. Manual chat command sent.
Same evening: deleted all 3 routines on this bot and recreated them from scratch. Also toggled the routine “Active” switch off/on.
Wed (Sep 2) 11:00 — opened the app at 10:59 (before scheduled time) as a workaround. Routine still did not start exactly at 11:00. It self-started spontaneously around 11:10 (~10 min late) and took ~23 minutes to complete (finished ~11:33).
Wed (Sep 2) 21:00 — failure again, despite the delete/recreate done the day before. No notification by +27 minutes. Opened the app and found the routine’s “Next run” field displaying “Run now” instead of a future scheduled time. Manual chat command sent at +31 minutes (21:31); response received at +45 minutes (21:45).

Possible factor 1 — instruction edits may be disrupting routine scheduling (requesting investigation):
The affected bot’s system instructions were edited multiple times across these days (unrelated content changes — trading logic, not scheduling). The routine worked correctly before these edits and started failing afterward. If editing a bot’s instructions does in fact reset or break its routine’s backend schedule binding, this itself would be the bug — a bot’s instructions and its routine schedule should be independent, and editing one should not silently break the other. Please confirm whether this is expected behavior or a bug.

Possible factor 2 — creation/access platform:
The affected bot’s routines were originally created on the Windows 11 desktop app; most later checks were via the iOS app. The consistently-working control routine (below) was created and has only ever been accessed via the iOS app. This is a secondary, less-confirmed hypothesis, since the affected bot did work correctly on desktop before edits began.

Control group (same account, different bot):
A separate routine on another bot, created on iOS, scheduled for 15:00 KST daily, has run successfully every day (2 consecutive days confirmed) without any manual intervention or app access — Run History shows “Success” at 15:13–15:17 both days (~13-17 min delay, always self-completing). This bot’s instructions have not been edited since creation.

Key observations:
Deleting and recreating the affected routines did NOT resolve the issue.
A ~10-20 minute delay before auto-start appears to be normal product behavior (seen on both the working control routine and once on the affected bot). This is distinct from the complete non-trigger failures described above.
Requesting investigation into whether frequent instruction/system-prompt edits disrupt a routine’s scheduled trigger.

Note: “자동 검토” (Auto Review) setting is currently ON for this account, with “자동 검토 규칙” (auto review rules) set to “없음” (none). Unsure if this could be related to routines silently waiting on an approval step. Time zone is confirmed correctly set to Asia/Seoul, ruling out timezone misconfiguration as a cause.

(Screenshot of the control routine’s success history available on request — upload failed repeatedly on this form.)

Steps to Reproduce

Not reliably reproducible on demand. It occurs intermittently on scheduled routines:

1. Create a recurring routine (e.g., daily at a fixed time) on a Grok Bot.
2. Wait for the scheduled time to pass without opening the app.
3. Check whether the routine auto-triggered.

Over 3 days, roughly half of the scheduled runs on the affected bot failed to auto-trigger (no notification, no Run History entry, “Next run” field stuck showing “Run now”). A separate bot’s routine (see description) has run successfully every time under the same conditions. Full incident timeline is in the description above.

Expected Behavior

Routine should auto-start at the scheduled time without requiring the user to open the app or send a manual message.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Pc Grok Bot version: 0.30.0
iOS Grok Bot Version: 1.4.0

For AI issues: add Request ID with privacy disabled

c3d42206-49b2-4bed-8bba-ba4c590554f0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Colin]

Hey @o_Oaii, thanks for the report, and for the timeline!

Two answers up front: editing a bot’s instructions does not touch its routine schedule, and the platform a routine is created on does not matter either. You can rule both out.

What is actually happening is on our side. Your routines did fire at every scheduled slot over the last few days, but each run sat in a queue before it started, so it began 10 to 37 minutes after the set time. That lines up with what you saw: Wednesday 11:00 started at 11:09 and finished 11:31, and Wednesday 21:00 started at 21:37 and finished 21:43. The “Next run” field reading “Run now” is that queued state (the slot is due, the run has not been handed to your bot yet), which is also why deleting and recreating the routines did not change anything.

The second half is why it looked like nothing ran at all: when those runs did execute, they finished without posting a message into the chat. Your 15:00 routine looks healthy by comparison because it writes to a file instead of messaging you, so there is nothing missing to notice there.

Both of these are known issues we are already tracking, and I have added your report to them.

In the meantime, you do not need to keep recreating the routines. Sending a message in the chat is still the reliable way to get a check-in on demand.

[o_Oaii (OAiii)]

Follow-up on the routine delay issue

I just updated the Grok Bot app to version 0.36.0, then clicked “Update Grok Bot Computer,” and restarted the app. After restarting, I got this warning:

“Routine sync failed. Grok Bot couldn’t sync this agent’s routines. Event-based routines will keep running locally while it’s safe, but scheduled routines may be delayed while retrying.”

Question: Is this warning just a general notice that applies to my case (i.e., informing me that scheduled routines — like the ones I reported earlier — may be delayed while retrying, which matches what you explained about the queue delay), or does this indicate a new/separate sync failure caused specifically by this update?

I want to confirm whether this is the same underlying mechanism you described earlier (routines firing on schedule but sitting in a queue before actually starting), or if the app update itself introduced an additional sync issue on top of that.

Screenshots attached (update screen showing v0.36.0 + Computer Update, and the sync failure warning that appeared after restart).

[Colin]

Hey @o_Oaii

That warning is a new, separate issue on our side, not the queue delay I described earlier, and it was not caused by your update.

A fix is rolling out on our side and the warning should clear on its own, so there is nothing you need to do.

[Parag_Chhibber]

Confirming this is still present on Grok Bot 0.39.0 (newer than the 0.30 / 0.36 reports in this thread).

Queue lag
Staff note that routines fire on the slot then sit in queue 10–37 minutes before the agent starts still matches what we see. On 2026-09-04 America/New_York we ran @every 5m / 10m / 15m probes after resetting collection around 13:00 ET. Gaps were irregular (~2–27+ minutes), including overdue first starts and a couple of back-to-back drains. That looks like queue drain, not a missed cron fire.

We now treat daily jobs as “started on time” if they begin within ~1 hour of the slot, and only worry after ~2 hours. Tight @every Nm intervals amplify the jitter and are a poor health check.

Two separate UI issues (same product surface)

1. Schedule prefix CRON_TZ=America/New_York … correlated with blank Routines UI history even when the agent’s on-disk runs.json / lastRunAt recorded successful runs. Removing the prefix (plain cron, account TZ) made history visible again.
2. Routines created or later update_state’d by the agent show provenance: untrusted and often disappear from the Routines list until a human recreates them (provenance: user). Agent edits of schedule/prompt can flip them back to untrusted.

When the UI history is empty we treat automations/*/runs.json as source of truth.

Not asking you to recreate routines as a fix — staff already said that doesn’t change the queue.

[eltonmelo]

Same issues here. Very simple routines do not start automatically at the scheduled time.

[Effective_Autism]

Additional evidence from Grok Bot 0.44.0 on macOS, tested September 8, 2026. All times below are UTC; schedules used Europe/Oslo.

The routine was asked to read an existing saved record through MCP and report the result in chat. It was enabled more than nine minutes before its scheduled time, with no new chat messages during observation.

• Silent success: due 00:15; Grok reported start 00:23:51.848 and finish 00:24:42.285. The UI showed Scheduled/Succeeded but no result before the next chat message at 00:41. No MCP result was exposed, so this does not establish that the read completed.
• Working control: a separate routine explicitly called native SendToUser for a start message, performed one MCP read, then called SendToUser for the result. Two scheduled runs started about 7m22s and 6m37s late, but reported reads within 78 seconds of starting. Correct results appeared without a wake-up message. One ran while the desktop app was closed; its result was already visible on reopening before any new message.
• Misleading completion time: one successful run’s history ended at 01:27:57.544, before its reported read at 01:28:39.749 and chat result timestamp 01:28:42.

UI results were observed directly; execution/read timestamps were reported by Grok from its exposed records, not independently exported backend telemetry. The control is not proof of a fix.

Expected: distinguish queued work, completed work and delivered results. Is the early “Succeeded” status tracking only part of the workflow, and is this covered by the known report-delivery bug?

Silent run’s Grok-reported request ID: d160a0de-d8bd-41d2-8063-ff3b7126e059.

Early-completion example’s Grok-reported request ID: 94a00036-a814-45ea-a594-f5bec4c84adb.

[Omar_Marino]

Without fixing this bug, Grok Bot is practically useless in many scenarios.

[Andrew_Simard]

I’ve worked around it by having it set up a webhook so that I can ping the main bot periodically and have it check for the missed schedules. So for example I have jobs “scheduled” for 7am, but I set up an external cron task that pings the main bot at 7:05 and tells it to deal with anything that didn’t start on its own. Not ideal. Hopefully temporary.