If you build Grok Bot templates, here's the thing to keep in mind: your routines don't run on your usage. They run on everyone else's.
When you share a template, the link shows the Bot's configuration, "including its identity, description, skills, and routines," and adding it "creates a copy on the recipient's account" (Bots docs). From then on it's their Bot, on their plan, spending their weekly usage. A routine that checks something every five minutes might look harmless in your own account. Copy it to a few hundred accounts and you've got a few hundred Bots waking up all day just to find out nothing happened.
Why it matters: one weekly pool
Which plans include Grok Bot. Under The X Subscription, "Grok Bot is included on Premium, Super, and Ultra plans. The Plus plan doesn't include Grok Bot" (Grok Bot on The X Subscription). As of Oct 17, 2026, the Pricing page lists Premium at $30/mo, Super at $100/mo and Ultra at $200/mo, with included usage of 4x, 15x and 50x the Plus level. Plus ($8/mo) and Free don't include Grok Bot. The Plans and billing help page says the same about Plus and Free, and adds that legacy Cursor plans (Pro, Pro+, Ultra, Teams) and linked SuperGrok or X Premium+ subscriptions still grant access.
How the pool works. On The X Subscription, Grok Bot "draws from the weekly shared pool across Grok, Grok Bot, and Cursor" (Grok Bot on The X Subscription). Usage limits says the pool is "shared across eligible Grok and Cursor surfaces for that seat rather than split into separate product quotas," and that "usage rates vary by product." When it runs out, extra usage is paid from prepaid top-up credit.
So your template's routines share a pool with your adopter's Grok chats and Cursor coding. If the template spends their week, their Grok and Cursor use runs short too, unless they pay for top-up credit.
The docs don't all say the same thing yet. The Grok Bot overview and Get started pages still describe access only as paid Cursor plans plus a linked SuperGrok, SuperGrok Plus or SuperGrok Heavy subscription. They don't mention The X Subscription. The X Subscription pages and the Plans and billing help page cover both. Treat the plan pages as the reference, and check x.ai/pricing for current terms before you tell anyone what a plan includes.
The run math
The Grok Bot help is blunt about it: "Each run spends usage, so a routine that runs often spends more than one that runs rarely. An hourly schedule, a short interval, or a Slack trigger on a busy channel can use a week of usage in a day" (Routines help).
The pool resets weekly, so watch the weekly column.
| Schedule | Runs per day | Runs per week | Runs per 30 days |
|---|---|---|---|
| Every 5 minutes (the minimum) | 288 | 2,016 | 8,640 |
| Every 15 minutes | 96 | 672 | 2,880 |
| Every 30 minutes | 48 | 336 | 1,440 |
| Hourly | 24 | 168 | 720 |
| Every 2 hours | 12 | 84 | 360 |
| Once a day | 1 | 7 | 30 |
| Weekdays at 8:00 AM | 1 on weekdays | 5 | about 22 |
Going from every 5 minutes to hourly is 12 times fewer runs. Going to once a day is 288 times fewer. Those are run counts, not costs. The docs don't publish a per-run price, and bigger runs spend more. But a run that never happens is the easiest saving there is.
Template makers on X have been making the same point this week (community reports, not xAI guidance).
Use an event, not a clock
A routine runs "on a schedule or, where supported, after an event" (Skills and routines). The routines help lists the events: "a Slack message, a GitHub, Linear, Sentry, or PagerDuty event, an email, or a webhook call" (Routines help).
- Email. Have the job start when mail arrives at the Bot's own address, instead of checking an inbox on a timer.
- Slack. A trigger can start "when the Bot is mentioned, when a word or phrase is mentioned, when you react to a message, or on any message," in one channel or all of Slack. The help page adds: "Keep the channel and phrase narrow."
- GitHub, Linear, Sentry, PagerDuty. Let the tool that knows something happened say so.
- Webhook. Anything that can send an HTTP POST can start the routine. The routine's Webhook section shows the URL and a key, which senders include as an
Authorization: Bearerheader. The JSON body is passed to the Bot along with the routine instruction. A 200 response "means Grok Bot accepted the call and started a run," not that the work is done (Routines help).
An event routine only runs when there's something to do. In the help page's words: "A routine that never runs doesn't spend usage."
Keep listeners narrow. The docs warn: "Avoid broad listeners such as 'every new message.' They create noise, consume usage, and increase the chance of acting on irrelevant input" (Skills and routines). A Slack trigger on "any message" in a busy channel is just polling with extra steps.
When you do need a schedule: check cheap, then exit quietly
Some sources can't send events: a public status page, a JSON file, an RSS feed. Those still need a schedule, but each run can be small.
The pattern:
1. Pick the widest schedule the job can live with. Most "watch" jobs are fine hourly or daily. If you set a short interval, routine schedules "must be at least five minutes apart" (Skills and routines). 2. Read the smallest thing that can show a change. A feed's newest item ID, a JSON updated_at field, or a page's last-modified date. Not the whole page, and not a screenshot. 3. Compare it with what the last run saw. Keep the last value in a small file. The Bot's computer keeps files between sessions. 4. If nothing changed, stop. No summary, no "all clear" message, no follow-up step. 5. Only if something changed, do the real work.
A quiet run is still a run: short, but not free. That's why an event beats even the best scheduled check. If the source can call a webhook, or a cheap outside tool can do the check and only call the webhook when something changed, the Bot never wakes for nothing.
Quiet when idle
A good template does nothing out loud when there's nothing to do:
- No "nothing new today" messages. Each one is a notification your adopter didn't need.
- Failing cleanly, not looping. Each run spends usage, so a routine that fails the same way every run is paying for nothing. Report the failure in one line and stop.
- Respecting time away. "Grok Bot may ask whether to keep routines running after a long period away and pause them if there is no response" (Skills and routines). Tell adopters to check paused routines when they come back.
Add a backstop. Event triggers can miss. On October 13, from 10:52 AM to 1:29 PM PT (12:52 to 3:29 PM CT), Cursor's status page reported that "many Grok Bot routines started by webhooks, Slack, git, email and Linear events didn't run," and that "events sent during this window weren't processed and won't be retried automatically." The routines help also mentions a known "Automation run rate limit exceeded" error, and runs that fail with it aren't retried automatically. A once-a-day sweep that uses the cheap check above catches anything an event missed, for 7 runs a week instead of 2,016.
Before and after: one template routine
Here's a "release watcher" routine as many templates ship it today:
> Before: Every 5 minutes, open the project's releases page and changelog. Summarize anything new and post it in this chat.
That's 288 runs a day on every adopter's account, each loading a full page, even when nothing changed.
Here's the same job rebuilt:
> After (event routine): When a webhook call arrives, read the JSON body. If it contains a release version and a release notes link, open the link and post a three-bullet summary in this chat with the link. If the body has no release link, stop without posting. Never post outside this chat without my approval. > > After (daily backstop): Every day at 8:00 AM in my time zone, fetch the project's release feed and read only the newest release ID. Compare it with the ID saved in release-watch/last-seen.txt. If they match, stop without posting anything. If they differ, summarize only releases newer than the saved ID, post the summary here, and then save the new ID. If the feed can't be reached, say so in one line instead of using old data.
That's 7 scheduled runs a week plus one run per real release, instead of 2,016 runs a week. The backstop also covers the docs' advice to include "a no-data and stale-data policy" and to "make retries idempotent where possible" (Skills and routines).
One detail to get right: schedules use the time zone in the adopter's Settings (Routines help), so write "in my time zone," not your own city.
A checklist before you share
- [ ] Every routine has a reason to run that often. Write the runs per week next to each one. If it's in the hundreds, ask whether an event can do the job.
- [ ] Event first wherever the source supports it.
- [ ] Narrow triggers. One channel and one phrase, not "any message."
- [ ] Cheap check first. Scheduled routines read a small field, compare it with the last value, and exit quietly when nothing changed.
- [ ] Quiet when idle. No "nothing new" posts.
- [ ] A daily backstop for event routines, so a missed event isn't lost.
- [ ] Failure is explicit. Missing or stale sources get reported in one line, not retried in a loop.
- [ ] Test run done on safe input. A test "performs real work" (Skills and routines).
- [ ] No secrets in the template. Webhook keys, API keys, internal URLs and customer data come out. A public link shows the routines to anyone who has it (Bots docs).
- [ ] Say what it costs. Tell adopters in the description that Grok Bot needs Premium or higher on The X Subscription (or an eligible legacy plan), and roughly how many runs a week the template makes.
Your template runs in other people's weeks. Build it so it only wakes up when there's something to do.