Grok Bot · Tutorial 10
Schedule Reliable Work with Grok Bot Routines
Turn one proven skill into a routine, run a real test, inspect its history, and keep risky actions behind approval.

0 of 14 complete
Last tested and updated: August 12, 2026
A routine tells one Bot when to run a workflow. It can run on a schedule or, where supported, after an event. The Bot works on its cloud computer, so your laptop can be closed.
That convenience removes the moment when you would normally notice a bad input or strange page. The safe order is simple: complete the task once, save the method as a skill, test it with new inputs, and only then create the routine.
Official documentation captured from SpaceXAI’s Skills and routines guide on August 12, 2026. This is a public documentation page.
What belongs in a routine
A useful routine names:
- The Bot that owns it
- The schedule and time zone
- The current input source
- The expected result
- The approval boundary
- The response when a source is missing
Use a prompt such as:
Every weekday at 8:00 AM Hong Kong time, run the Daily research brief skill against the current source list. Save a linked brief in this conversation. Do not send or publish it. If a source is unavailable, report the failure instead of reusing old information.
The Bot should show the next run after creating the routine.
Start with preparation, not execution
The safest first routines prepare work for you:
- Draft a report for review.
- Reconcile two lists and flag differences.
- Collect linked evidence.
- Recommend changes without applying them.
- Prepare messages without sending them.
Keep sending, publishing, purchasing, deleting, permission changes, and production changes behind approval. A recurring job can repeat a mistake many times before you notice it.
Build your first scheduled routine
1. Choose a proven skill
Use a skill that has already passed several manual runs with different inputs. If the workflow still needs clarification every time, it is not ready for a schedule.
2. Define current inputs
Do not say “use the usual list” unless the source is explicit. Point to a folder, connector, project, or URL that will still be correct next week.
3. Define the no-data rule
Tell the Bot what to do when nothing is available:
If the source cannot be opened or is older than 24 hours, report which check failed and stop. Do not use cached or previous-run data.
4. Set the approval boundary
Name the external actions the routine cannot take. Do not rely on a vague request to “be careful.”
5. Create the schedule
Ask the Bot that owns the job to create the routine. Confirm the time zone and next run.
6. Run a test
Use Test run. Watch which inputs it selects, where it saves the result, and whether it stops at the approval point.
7. Inspect the run record
Open the Bot, choose View conversation details, then Routines. Review the result and any failure rather than accepting a green status alone.
Test the failure path on purpose
Before enabling a daily schedule, temporarily point the routine to a missing test file or unavailable test source. It should:
- Report the missing source.
- Avoid using old data.
- Stop before creating a misleading deliverable.
- Leave a clear run record.
- Notify you through the channel you chose.
If it silently skips the source, fix the skill and retest.
Manage routines
The Routines view lets you enable or pause a routine, run a test, edit its schedule or instructions, inspect success and failure history, and delete it.
Current documented limits are:
- One Bot can own up to 50 routines.
- Grok Bot keeps the 20 most recent run records for each routine.
- Deleting a routine is immediate and has no undo.
- Deleting a Bot also removes the routines it owns.
Hiding a Bot does not pause its routines. If a Bot leaves your active roster, check its routines separately.
Grok Bot may ask whether to keep routines running after you have been away for a long period. It can pause them if you do not respond. Review paused routines when you return.
Scheduled or event-triggered?
Use a schedule when time starts the job: every weekday morning, every Friday afternoon, or once a month.
Use a supported event trigger when a narrow event starts the job, such as a Slack message or GitHub notification. Cursor account integrations for event triggers are separate from Slack or GitHub plugins and may require their own connection flow.
Keep event filters narrow. “Every new message” creates noise, uses more allowance, and increases the chance that the Bot acts on irrelevant content.
Example:
When a message in
#customer-escalationscontains a support ticket link and the phrase “needs repro,” open the ticket, reproduce it in staging, and save a repro pack in this conversation. Never post back to Slack without approval.
Practical exercise: weekday research brief
Prepare the skill
Build a skill that reads three named public sources and returns:
- The two newest relevant items
- A one-sentence summary of each
- A direct source link
- The publication date
- A section for missing or unavailable sources
The skill must not send or publish anything.
Create the routine
Every weekday at 8:00 AM Hong Kong time, run the Morning source brief skill. Use only the three sources listed in the skill. Save the linked result in this conversation. If a source is unavailable or has no new item, say so. Do not send, publish, subscribe, or sign in.
Run the test checklist
- Confirm the owning Bot.
- Confirm the next run time and time zone.
- Run once with all sources available.
- Run once with one safe test source unavailable.
- Verify that every item has a link.
- Verify that the Bot does not reuse an old item as new.
- Check the run history.
- Pause the routine and confirm it shows as paused.
- Resume only after the failure test passes.
Success criteria
- Manual and scheduled results use the same format.
- The run uses current sources.
- Missing data is reported plainly.
- No external action occurs.
- The result and failure are readable in run history.
- The routine can be paused and resumed without losing its instructions.
Common failures
| Failure | Why it happens | Fix |
|---|---|---|
| The job uses yesterday’s data | The input or stale-data rule is vague | Name the live source and maximum age |
| The schedule fires at the wrong hour | The time zone was not confirmed | Put the city or time zone in the instruction and inspect the next run |
| A test changes real data | Test run performs real work | Use a sandbox and require approval for every write |
| The routine fails without a useful message | No failure-reporting rule exists | Require the failed source, step, and last completed action |
| Duplicate actions appear after retry | The workflow is not idempotent | Check whether the intended record already exists before creating it |
| A hidden Bot keeps working | Hiding does not pause routines | Pause the Bot’s routines in conversation details |
| Old routines consume allowance | No regular review exists | Review active routines and recent runs every week |
A weekly routine review
Once a week, check:
- Which routines ran?
- Which failed or needed intervention?
- Did any use stale data?
- Did permissions or source formats change?
- Are any routines producing work nobody reads?
- Should any routine be paused, simplified, or deleted?
Three routines you trust are better than fifty jobs you no longer inspect.
What the source video adds
At 06:24, Alex Finn describes routines as scheduled automations with tests and run history. He also says a Bot can recommend routines based on existing work. His example turns weekly videos into newsletters.
Use the suggestion as an idea generator. Review any proposed routine with the same checklist as one you wrote yourself. The current SpaceXAI documentation is authoritative for test-run behavior, limits, history retention, event triggers, and deletion behavior.