Grok Bot: A Routine Every 5 Minutes Costs 12x More Than Hourly (Full Course)
One Grok Bot routine on a 5-minute clock wakes up 8,640 times a month.
At Grok 4.6 API rates that's about $400 of compute for one job. Hourly, it's $33. Same bot, same model, same prompt. The only thing that changed is how often it wakes up.
On a subscription you won't see that bill. You'll see your plan's allowance burn 12x faster, mostly on runs where nothing happened.
Everyone setting up Grok Bot is arguing about which bot to hire and how to split the team. Almost nobody is looking at the clock. And the clock is where the bill, the noise and the 3 a.m. failures come from.
This is the full course on routines: how often to run them, when not to schedule at all, how to make a fast routine cheap, what happens when one needs you while you sleep, and a script that tells you which ones to kill.
TLDR: trigger on events instead of polling where you can, pick the slowest schedule the job can live with, put a cheap "did anything change?" check in front of every fast routine, never let a night routine wait for your approval, and keep your own run log because Grok Bot only keeps 20.
1. The numbers first
routines per bot up to 50
fastest schedule every 5 minutes
runs per month at 5 min 8,640
50 routines x 5 min 432,000 runs a month
background approval window ~10 minutes, then it expires
run history kept per routine 20 runs (= 1h 40m at 5 min)
bots on one account share one cloud computer
Grok 4.6 API, per 1M tokens $2 in · $0.50 cached · $6 out
one full run, my example 20K in + 1K out ≈ $0.046
one 5-min routine, API rates ≈ $397 a month
same routine with a change check ≈ $45 a month
same job on an event trigger $0 for the runs where nothing happened
Limits are from the official routines docs and approvals docs. Costs are my math at API rates, used as a yardstick. Grok Bot bills against your plan's own allowance, so the real meter is the usage view in the app.
2. Why the clock matters more than the model
A chat costs you once. A routine costs you every time it fires, forever, whether or not anything happened.
Most routines are checks. Did a competitor change their pricing page, did CI break, did someone reply, is a card stuck on the board. Most of the time the answer is no.
So the 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. Double the frequency and you double the bill. You almost never double the value.
3. The cadence table
Same routine, same 20K tokens read and 1K written per run:
CADENCE RUNS / MONTH COST / MONTH
every 5 min 8,640 $397
every 15 min 2,880 $132
every hour 720 $33
4x a day 120 $5.52
once a day 30 $1.38
Going from hourly to every 5 minutes is 12x the cost. Ask yourself what you'd actually do with the extra 55 minutes of freshness.
What's usually enough: CI and 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, audits once a night.
Start slow. Speed a routine up only when a real miss proves it's too slow.
https://pbs.twimg.com/media/HURx5cGX0AAnZgY.jpg
4. 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. A trigger waits to be told. Grok Bot routines can start from events instead of a clock: a Slack message, a GitHub notification, a webhook with its own URL and key, and since this week an email to the bot's own address.
One catch from the same announcement: in a team, an admin has to switch the inbox on before any bot can use it.
The docs add one warning that matters a lot here: "Avoid broad listeners such as 'every new message.'" A trigger that fires on everything is just a 0-minute schedule.
So the rule is simple:
- If the system can send an event, use a narrow trigger. Not "any message in #eng", but "a message in #deploys that contains FAILED".
- If it can't, use a schedule with a change check (next step).
- If a GitHub routine only watches one pull request, it already ignores events from other PRs and removes itself once the PR merges or closes. Use that instead of a repo-wide watcher.
A trigger prompt you can paste:
Create a routine triggered by a webhook.
When it fires, read only the request body. Expect JSON with
"service", "status" and "url".
If status is not "failed", do nothing and stop.
If it is "failed", open the url, find the first error line, and post
to <a href="https://twitter.com/hashtag/incidents" target="_blank" rel="noopener noreferrer" class="hashtag-link" onclick="event.stopPropagation()">#incidents</a>: service, the error line, one guess at the cause,
and the link. 4 lines max. Never retry the deploy yourself.
5. The change check: make a fast routine cheap
Sometimes you really do need 5 minutes and there's no event to listen to. A launch is live, a page you don't own is moving fast.
Don't make the full run cheaper. Make most runs not be full runs.
Split it in two. First a tiny check that reads a hash, a count or a timestamp, about 2K tokens, and answers in one word. Then the real work, only if the check says something changed.
If something actually changes about 6 times a day:
WITHOUT A CHECK 8,640 full runs x $0.046 = $397
WITH A CHECK 8,640 checks x $0.0043 = $37
180 full runs x $0.046 = $8
total = $45 (-89%)
Same 5-minute reaction time, about a ninth of the cost.
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 in routines/state/[name].txt.
If it is the same, append "no_change" to the log 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].
Post the result to [destination] in 5 lines max.
The "do not take a quick look around" line is doing real work. Without it the bot tends to explore while it's there, and you're back to paying for full runs.
6. The 3 a.m. problem
From the approvals docs: an approval from work that started without you, like a routine, a trigger or a message from another bot, "expires after about 10 minutes". The card shows Expired and the action doesn't run.
Do that over one night. You sleep 8 hours, a 5-minute routine that needs your OK fires 96 times, and all 96 approvals expire. Nothing breaks and nothing gets done. You wake up to a column of grey cards.
Every routine that runs while you're away needs its ending decided in advance:
- Allow it. The action is safe and reversible, and you've already approved it five times in a row. Write a Custom Rule for it. Expired cards even offer "Always allow this in the future", which is the app telling you the same thing.
- Stop at a draft. The action isn't safe, so the routine leaves a draft in a queue and you deal with it at breakfast.
There's no third option where the bot waits for you. It looks like it exists. It silently does nothing.
https://pbs.twimg.com/media/HURx9pIXYAAFF3F.jpg
7. Keep your own run log
The docs: "the app keeps the 20 most recent run records for each routine." At 5 minutes, that's the last hour and 40 minutes. If something broke at 2 a.m. and you look at 9, the evidence is gone.
So every routine ends by writing one line to its own file. 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 missing.
The bots share one cloud computer, so the logs sit next to the work and any bot can read them.
8. The script that tells you what to kill
Run this weekly on the logs folder. It prints one line per routine and flags the ones that are costing you for nothing:
import csv, sys
from pathlib import Path
RUN_COST = 0.046 # your full-run estimate in $, see section 1
CHECK_COST = 0.0043 # a no_change run, if the routine has a change check
def verdict(no_change, failed, runs):
if runs == 0:
return "dead: never ran, check the schedule"
if failed > 0.10:
return "PAUSE: fails too often"
if no_change > 0.99:
return "DELETE or make it daily"
if no_change > 0.95:
return "slow down or add a change check"
return "keep"
folder = Path(sys.argv[1] if len(sys.argv) > 1 else "routines/log")
rows = []
for f in sorted(folder.glob("*.csv")):
runs = list(csv.DictReader(f.open()))
n = len(runs)
nc = sum(r["result"] == "no_change" for r in runs)
fl = sum(r["result"] == "failed" for r in runs)
dr = sum(r["result"] == "draft_left" for r in runs)
cost = nc * CHECK_COST + (n - nc) * RUN_COST
share = nc / n if n else 0
rows.append((share, f.stem, n, fl / n if n else 0, dr, cost))
print(f"{'routine':24} {'runs':>6} {'no_change':>10} {'failed':>7} {'drafts':>7} {'est $':>8} verdict")
for share, name, n, failed, drafts, cost in sorted(rows, reverse=True):
print(f"{name:24} {n:6} {share:10.0%} {failed:7.0%} {drafts:7} {cost:8.2f} "
f"{verdict(share, failed, n)}")
Save it as audit.py and give it to your front-door bot as a weekly routine:
Every Monday at 9:00, run: python audit.py routines/log
Post the output to me as-is. Then list any routine marked DELETE or
PAUSE and ask me which ones to remove. Do not delete anything yourself.
The top of that list is where your money is going. A routine that's 99% "no change" isn't monitoring, it's a fee. And if you'd only notice a routine was gone because its log stopped growing, it was never doing a job.
9. Five things the changelog will teach you the hard way
Four of these come straight from the official Grok Bot changelog and docs. Number 4 is my own design rule. Each one changes how you build a routine.
- Chatting with a bot mid-routine costs you a second run. "If you message your Bot while a routine is running, the routine runs again afterward." Don't talk to a bot during its heavy routine unless you mean it.
- A test run is a real run. The docs: "A test run performs real work. It can navigate websites, change files, and call connected tools." Test on a copy, never on the live inbox.
- Schedules count from when you create them. Hourly, interval and daily routines are counted from creation time. Create the 9:00 report at 9:00, not at 9:37.
- Don't count on a missed run being made up. If the bot is paused or busy, a slot can pass without a run. Build each run to catch up on everything since the last logged success, so a skipped slot costs you a delay, not data.
- Long absences pause things. Grok Bot may ask whether to keep routines running after a long period away and pause them if you don't answer. Back from a holiday? Check the routines list first.
10. The guards
the system can send an event -> narrow trigger, not a schedule
schedule faster than hourly -> needs a change check
routine runs while you sleep -> Custom Rule to allow, or stops at a draft
trigger on "every new message" -> rewrite it to match one thing
email trigger in a team -> admin has to enable the inbox first
history matters -> routine writes its own log line
no_change over 99% -> delete it or make it daily
testing a new routine -> safe copy, it does real work
logins on the shared computer -> every bot can use them
11. What I haven't tested
The cost numbers. They're Grok 4.6 API rates used as a yardstick. Grok Bot bills against your plan's allowance and xAI doesn't publish how big that allowance is.
Tokens per run. 20K in and 1K out is an example. A routine that opens a heavy page or a long thread reads far more, and the costs scale with it.
How often things change. "6 times a day" in the change-check math is an assumption. On a quiet page the savings are bigger, on a busy one smaller.
How well the bot sticks to "check only". The change-check prompt relies on the bot not exploring. I'd confirm it in the log for a few days before trusting it.
12. The playbook
Price the clock, not the run.
If it can ping you, don't poll it.
Start at the slowest schedule the job can live with.
Fast routine with no event? Cheap check first, full run only on change.
Decide the night ending in advance: allow rule or draft. Never "wait for me".
Every routine writes its own log line, and a script reads them on Monday.
Delete anything that's 99% "no change" or that nobody read in two weeks.
The point
Hiring the right bot and building the team are the two questions everyone asks about Grok Bot. Both matter.
But once the team exists, the thing that decides your bill and your mornings is the clock. A routine doesn't cost what one run costs. It costs that times every time it wakes up for nothing.
Listen for events. Check before you work. And decide what happens at 3 a.m. before 3 a.m. arrives.
Sources: Grok Bot routines docs, approvals docs, Grok Bot changelog, as of October 10, 2026. Costs are my estimates at Grok 4.6 API rates, not a measured Grok Bot bill.
If you want more breakdowns like this, I post one every couple of days on Telegram and X. Both free.
X - https://x.com/gippp69
telegram - https://t.me/GipArcAI