Grok Bot Routines: How Often Should They Run?

Everyone setting up Grok Bot argues about which Bot to build and how to split the work between them. Almost nobody looks at the clock. And the clock is where the cost, the noise, and the failures you wake up to actually come from.

A chat costs you once. A routine costs you every time it fires — whether or not anything happened. Most routines are checks: did a competitor change their pricing page, did a build break, did anyone reply, is a ticket stuck. Most of the time the answer is "no." So the real cost of a routine isn't the price of one run. It's the price of one run times every time it wakes up for nothing.

This guide is built only on Grok Bot's own documentation and xAI's published API pricing. The dollar figures are a yardstick (more on that below), not a bill. But the lesson holds: price the clock, not the model.

First, the numbers that matter

From the routines documentation, a few hard limits shape every decision:

• A Bot can own up to 50 routines.
• Schedules must be at least five minutes apart — five minutes is the floor.
• Grok Bot keeps only the 20 most recent run records per routine (at five minutes, that's the last hour and 40 minutes of history).
• Background routines can run while your laptop is closed.
• All of your Bots share one cloud computer.

And the price of the work itself. xAI's current flagship, grok-4.7, costs $2.00 per million input tokens and $6.00 per million output tokens (x.ai/api). Take one routine that reads about 20,000 tokens and writes about 1,000 each time it runs. That's roughly $0.046 per run.

Why the clock beats the model

Here is the same routine — same 20,000 tokens in, 1,000 out — on different schedules for a 30-day month:

Going from hourly to every five minutes is 12 times the work and 12 times the cost. You almost never get 12 times the value. The honest question for every routine is: what would you actually do with 55 extra minutes of freshness that you can't do with an hourly check?

What is usually enough: build or PR status every 15 minutes on an active repo, inbox triage hourly, competitor pages and docs once a day, reports and board reviews once on a schedule, overnight audits once a night. Start at the slowest schedule the job can live with. Speed a routine up only when a real miss proves it's too slow.

A must-read caveat on the money. Grok Bot runs on your plan's usage allowance, not on per-token API billing. So you won't see a $397 line item — you'll see your allowance burn about 12x faster, mostly on runs where nothing happened. The dollar figures here use xAI's published API rates as a yardstick to compare how much compute each schedule burns. The real meter is the usage view in the app. The token counts per run (20K/1K) and the change frequency used later are examples; your numbers will differ.

Don't poll what can ping you

The cheapest routine run is the one that never happens. A schedule asks "anything new?" every N minutes. An event trigger waits to be told. Grok Bot's account integrations can start a routine from an event — for example a Slack message or a GitHub notification — instead of a clock (docs). These are set up through their own connection flow, separate from the regular plugins.

The documentation gives one warning that matters enormously here: "Avoid broad listeners such as 'every new message.'" A trigger that fires on everything is just a five-minute schedule wearing a costume. So the rule is:

1. If the system can send an event, use a narrow trigger. Not "any message in #eng," but "a message in #deploys that contains the word FAILED."
2. If it can't, use a schedule with a change check (next section).

The documentation's own example follows this shape: a trigger that fires only when a message in a specific channel contains both a ticket link and a particular phrase, then reproduces the issue in staging and posts the result in the conversation — and never posts anything back out without approval. Narrow match in, clear action out, and a hard stop before anything leaves the building.

Make a fast routine cheap: the change check

Sometimes you really do need five minutes and there's no event to listen to — a launch is live, or a page you don't own is moving fast. Don't make the full run cheaper. Make most runs not be full runs.

Split the routine in two. First a tiny check that reads one small thing — a status field, a last-commit hash, a count, a "last updated" timestamp — about 2,000 tokens, and answers in one word. Then the real work, only if the check says something changed.

Say the thing you're watching actually changes about six times a day. A cheap check costs roughly $0.004 a run. The math changes completely:

Same five-minute reaction time, about 89% less compute. The instruction that makes it work looks like this:

Every 5 minutes:

CHECK
Open [the page / repo / board]. Read ONLY [the status field / last
commit hash / count of open items / "updated" date]. Compare it to
the value saved in routines/state/<name>.txt. If it is the same,
log "no_change" and stop. Do not open anything else. Do not take a
quick look around.

WORK (only if it changed)
Save the new value to routines/state/<name>.txt, do the actual job,
and post the result in 5 lines or fewer.

That last line in the CHECK step — do not take a quick look around — is doing real work. Without it, the Bot tends to explore while it's already there, and you're quietly back to paying for full runs.

The 3 a.m. problem

Here is the one that bites people. From the approvals documentation: an approval for work that started without you — a routine, a trigger, or a message from another Bot — expires after about 10 minutes. The card then shows Expired, and the action does not run.

Play that out over one night. You're asleep for eight hours. A five-minute routine that needs your approval fires 96 times, and all 96 approvals expire. Nothing breaks, and nothing gets done. You wake up to a column of grey cards.

There is no third option where the Bot politely waits for you until morning. It looks like there is. There isn't. So every routine that runs while you're away needs its ending decided in advance:

1. Allow it automatically. If the action is safe, reversible, and you've approved it several times already, write an Allow automatically rule for it (Settings → General → Auto-review). An Expired card even offers "Always allow this in the future," which adds exactly that rule.
2. Stop at a draft. If the action isn't safe to run unattended, design the routine to leave a draft or a recommendation in the conversation, and deal with it over coffee.

One more thing to know about those rules: Grok Bot's Auto Review has "Ask first" rules and "Allow automatically" rules, and if both match, "Ask first" wins. So a single "ask me before any external email" rule reliably stops a whole class of actions, no matter what else you've allowed.

Keep your own run log (Grok Bot only keeps 20)

The app keeps the 20 most recent run records per routine. At five minutes, that's only the last hour and forty minutes. If something went wrong at 2 a.m. and you look at 9, the evidence is already gone.

Since all your Bots share one cloud computer and can write files, the fix is to have each routine write its own one-line log. Add this to the end of every routine:

After every run, append one line to routines/log/<name>.csv:
time,result,changed,minutes,needed_approval,note

result is one of: ok, no_change, draft_left, failed
note is under 12 words. Create the file with that header if it's missing.

Once the log exists, a weekly review tells you what to kill. A routine that logs "no_change" 99% of the time isn't monitoring anything — it's a standing fee. And if you'd only notice a routine was gone because its log stopped growing, it was never doing a job worth paying for.

Before you enable anything: test

One trap worth naming. The docs are blunt: "A test run performs real work. It can navigate websites, change files, and call connected tools." A test run is not a dry run. Test on a safe copy with safe inputs, and keep every write action behind approval while you're testing. And remember: deleting a routine is immediate and has no undo, and deleting a Bot removes the routines it owned.

The whole thing on one card

• The system can send an event → use a narrow trigger, not a schedule.
• Schedule faster than hourly → it needs a change check in front.
• Routine runs while you sleep → an Allow-automatically rule, or it stops at a draft. Never "wait for me."
• Tempted by "every new message" → rewrite it to match one thing.
• History matters → the routine writes its own log line (Grok Bot keeps only 20).
• A routine that's 99% "no change" → slow it down or delete it.
• Testing a new routine → it does real work, so use a safe copy.

Price the clock, not the run. If it can ping you, don't poll it. Check before you work. And decide what happens at 3 a.m. before 3 a.m. arrives.

Want the hands-on version — build a cheap, quiet, safe routine step by step, with the change-check pattern and the overnight rules? Take the free course: Grok Bot Routines, Done Right. It's part of our free AI courses on Toolglade Learn.