Routines best practices
How we write routine instructions so they run on time, stop when done, cost little, and don't die quietly. Limits to know: 50 per Bot, 20 run records, inactivity pause.
Short answerEvery routine instruction has four parts: when it runs, what it reads (bounded), what it produces, and when it stops. Add an action cap per run and a heartbeat line. Fewer, better-shaped routines beat many rarely-run ones.
Skill first, then routine
The official guidance is right: start with a one-time task, make it reliable, save it as a skill (steps, decision rules, expected output, safety boundaries), and only then put it on a routine. A routine wrapping an unreliable skill is an expensive way to be wrong on a schedule.
The four-part shape
- When: explicit cadence or trigger. "Daily at 06:00", not "regularly".
- What it reads: bounded. "Emails received since the last run", not "the inbox".
- What it produces: a specific artefact. "A draft per invoice, saved as bill drafts", not "handle invoices".
- When it stops: "After processing today's items, or after 25 actions, whichever first. Report and stop."
Rules
- No "monitor", "keep checking", "until done" without a cadence and a cap.
- One heartbeat line per completed run to a log file. A daily watcher reads it.
- Test supervised three times before scheduling.
- Trigger-only routines get a light daily heartbeat run so they don't get paused for inactivity.
- Fold rare tasks into one daily "ops" routine that checks what's due.
- Re-test every routine after a Grok Bot update. Check the changelog.
Limits
50 routines per Bot. 20 most recent run records per routine. Long-inactive routines pause automatically. Event triggers exist via Cursor integrations (Slack message, GitHub notification).
Verified 28 Aug 2026 · Facts about Grok Bot change during beta. See changelog.