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.

Paper clockwork calendar running a checked skill cartridge through history and approval gates.
Reading time
13 min
Last updated
August 2026

0 of 14 complete

Complete & next →

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 SpaceXAI documentation defining skills and routines and recommending that users first make a one-time task reliable

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:

  1. Report the missing source.
  2. Avoid using old data.
  3. Stop before creating a misleading deliverable.
  4. Leave a clear run record.
  5. 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-escalations contains 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

FailureWhy it happensFix
The job uses yesterday’s dataThe input or stale-data rule is vagueName the live source and maximum age
The schedule fires at the wrong hourThe time zone was not confirmedPut the city or time zone in the instruction and inspect the next run
A test changes real dataTest run performs real workUse a sandbox and require approval for every write
The routine fails without a useful messageNo failure-reporting rule existsRequire the failed source, step, and last completed action
Duplicate actions appear after retryThe workflow is not idempotentCheck whether the intended record already exists before creating it
A hidden Bot keeps workingHiding does not pause routinesPause the Bot’s routines in conversation details
Old routines consume allowanceNo regular review existsReview 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.

Sources