Subtopics 6.1 and 6.2 covered skills — the recipe book. Subtopic 6.3 is the trigger: cron. Cron is what fires a skill on a schedule so the recipe runs while you sleep. Without cron, skills are only useful when you remember to call them. With cron, the daily briefing lands in your Discord at 7 AM every morning, and the only thing you had to do was write the recipe and the schedule once.

The cron syntax itself is short — five fields, twelve special characters, a handful of common patterns. The deeper question is when to fire, and the channel's answer is tied to the 5-hour refresh window on the token plans. The Minimax coding plan gives 100 prompts every 5 hours; the cron jobs have to fit inside that window or the chain breaks. The 5-hour refresh window is the channel's automation heartbeat, and cron schedules are designed to fit it.

This article walks through the cron syntax, the field-by-field breakdown, the common patterns, the time-zone gotcha, the API-key gotcha, and the 5-hour-budget design rule. Skills are the muscle; cron is the nerve; the refresh window is the heart rate. This article is the heart rate.

What you'll learn

  • Cron syntax is minute hour day month weekday — five fields, each with a value or wildcard. The common patterns are 0 7 * * * (daily at 7 AM) and 0 */6 * * * (every 6 hours) (09-cron-jobs.md source).
  • The Minimax coding plan gives 100 prompts every 5 hours on the starter tier (258R3kzDRAQ, transcript). Cron jobs that fit inside a single 5-hour window don't bust the budget; cron jobs that span the refresh boundary do.
  • The channel's standard pattern: a 5-hour window contains a chain of cron jobs (the morning pipeline: 6 AM Twitter, 7 AM brief, 7:30 AM slides, 8 AM Discord), and the chain restarts cleanly at the next refresh.
  • Cron jobs run in a different environment than interactive sessions. API keys have to be in every config location (config.json, providers/*.json, auth/profiles.json, .env), or the cron job fails silently (09-cron-jobs.md source).
  • Time-zone gotcha: the server's time zone may not be yours. Set TZ=America/New_York (or your zone) in the OpenClaw config, and verify by asking the agent "what time zone are you using?" (09-cron-jobs.md source).
  • Test every cron job before scheduling it for production. The host's rule: "Schedule for 2 minutes from now → Verify → Then schedule production time" (09-cron-jobs.md source). Never schedule for 3 AM and hope.

The cron syntax

The format is five space-separated fields, in this order (09-cron-jobs.md source):

*    *    *    *    *
│    │    │    │    │
│    │    │    │    └─ weekday (0-7, 0=Sun, 7=Sun)
│    │    │    └────── month (1-12)
│    │    └─────────── day (1-31)
│    └──────────────── hour (0-23)
│    ───────────────── minute (0-59)

Each field accepts a value, a wildcard * (any), a step */n (every n), or a range n-m. The weekday field accepts 0-7 with both 0 and 7 meaning Sunday.

Common patterns

The patterns the channel uses (09-cron-jobs.md source):

# Hourly
0 * * * *        # Top of every hour
*/15 * * * *     # Every 15 minutes

# Daily
0 9 * * *        # 9:00 AM every day
30 14 * * *      # 2:30 PM every day

# Weekly
0 9 * * 1        # Monday at 9:00 AM
0 17 * * 5       # Friday at 5:00 PM

# Monthly
0 0 1 * *        # First day of month at midnight
0 9 15 * *       # 15th of every month at 9:00 AM

# Every 6 hours (the channel's research sweep)
0 */6 * * *      # 00:00, 06:00, 12:00, 18:00

The 0 */6 * * * pattern is the cadence for the 6-hour research sweep in 6.5. It's the right interval for "monitor the world for new developments" — frequent enough to catch trends, sparse enough that each run has new content to analyse. The host's data: 6-hour runs found 15-30 new items per cycle; hourly runs found fewer than 5 (14-subagent-blueprint.md source).

The 5-hour refresh window

The channel's token-plan cadence is 5 hours. The Minimax coding plan gives 100 prompts every 5 hours on the starter tier (258R3kzDRAQ, transcript). The cron jobs have to fit inside a single 5-hour window or they get cut off at the refresh boundary.

The practical rule: design your cron chain so all the jobs in a logical workflow fire within a 5-hour window. The morning pipeline (6 AM, 7 AM, 7:30 AM, 8 AM) fits in a 2-hour window, leaving 3 hours of headroom for retries or follow-up jobs. The 6-hour research sweep (0 */6 * * *) fires at 00:00, 06:00, 12:00, 18:00 — each fire fits in the same 5-hour window as the morning pipeline, with no cross-window dependencies.

What you don't do: schedule a job that takes 4 hours to run, then schedule the next job 30 minutes later. The 4-hour job crosses the 5-hour refresh boundary, the budget resets, and the second job starts from zero budget. The chain is no longer deterministic.

The host's framing: the 5-hour window is the budget envelope for a workflow. Treat each cron job as a "spend" against the budget, and design the schedule so the cumulative spend fits.

The time-zone gotcha

Cron runs in the server's time zone, not yours. If the server is in UTC and you're in America/New_York (UTC-5), a 0 7 * * * cron fires at 2 AM your time, not 7 AM. The host's diagnostic steps (09-cron-jobs.md source):

# Check server time zone
date
timedatectl

# Check OpenClaw time zone
echo $TZ

The fix: set the time zone in the OpenClaw config, not just the shell:

{
  "timezone": "America/New_York"
}

Or set the TZ environment variable in the OpenClaw service file. The host's verification line: ask the agent "what time zone are you using for cron jobs?" If the answer doesn't match your wall clock, the config didn't take.

The silent failure mode: the cron job fires on time (server time), the skill runs, the output lands in Discord at 2 AM, and you don't see it until morning. By then, the brief is 5 hours stale. The fix: always verify the time zone when you install a new cron, and re-verify after any server move or timezone change.

The API-key gotcha

Cron jobs run in a different environment than interactive sessions. The shell that runs the cron has a different environment, a different set of loaded variables, and a different working directory. If your API key is in ~/.bashrc but not in the cron's environment, the cron job fails with "API key not found" (09-cron-jobs.md source).

The host's checklist for Minimax (09-cron-jobs.md source):

# 1. Main config
~/.openclaw/config.json

# 2. Provider config
~/.openclaw/providers/minimax.json

# 3. Auth profiles
~/.openclaw/auth/profiles.json

# 4. Environment variables
~/.openclaw/.env

The API key has to be in every location, because cron reads from a different env than your interactive shell. The host's verification: "Test my Minimax API key configuration for cron jobs." If the test passes, the key is wired up; if it fails, you've missed a location.

The silent failure mode: the cron job fires, the skill starts, the first API call fails, the skill logs "API key not found" to stderr, and the job exits with a non-zero code. The Discord notification (if any) goes out as "failed." You check the logs in the morning, fix the missing key, and re-schedule.

The host's fix: put the key in ~/.openclaw/.env and source it from the OpenClaw service. The service file is the one place that runs for both interactive and cron sessions, and the .env is loaded by the service, so the key is in scope for both. The skill then reads the key from the environment, not from a hard-coded path.

Testing before scheduling

The host's rule: never schedule a cron for 3 AM and hope. The pattern (09-cron-jobs.md source):

  1. Create a test cron. "Create a cron job that runs in 2 minutes to test my daily briefing workflow."
  2. Monitor execution. "Watch for cron job completion notification."
  3. Verify output. "Check if briefing was generated correctly. Review Discord/Slack for delivery. Confirm all data sources were accessed."
  4. Fix issues. "If failed: debug and fix. If successful: schedule for production time."

The test window is 2 minutes, not "later tonight." The host's reasoning: if the cron is wrong, you want to know while you're awake, not while you're sleeping. A 2-minute test catches every failure mode (missing API key, wrong time zone, broken skill chain) in real time, with you at the keyboard.

Common test failures

The four failures the host calls out (09-cron-jobs.md source):

  • Missing API keys. Error: "OpenAI API key not found." Fix: verify keys in all config locations.
  • Skill not found. Error: "Skill 'daily_briefing' does not exist." Fix: check skill file location and name.
  • Permission denied. Error: "Cannot write to memory/daily/." Fix: check file permissions with chmod 755 memory/.
  • Timeout. Error: "Job exceeded 30 minute timeout." Fix: optimise the workflow or increase the timeout.

Each failure has a clear signature. The 2-minute test surfaces them all.

Common cron patterns for skills

The host's library of cron + skill patterns (09-cron-jobs.md source):

Daily briefing at 7 AM

0 7 * * * Execute skill: daily_briefing

Fires the daily_briefing skill at 7 AM every day. The skill handles research, analysis, presentation, delivery — the cron just fires the trigger.

Twitter intelligence at 6 AM

0 6 * * * Execute skill: twitter_intelligence

Fires the twitter_intelligence skill at 6 AM. The skill scrapes monitored accounts, saves tweets to JSON, posts a summary to Discord. The cron is one line; the skill is the recipe.

6-hour research sweep

0 */6 * * * Execute skill: ai_research_pipeline

Fires the ai_research_pipeline skill every 6 hours. The skill spawns parallel sub-agents for Twitter, news, Reddit, HN, runs gap analysis, saves the result. This is the worked example in 6.5.

Weekly report on Mondays

0 9 * * 1 Execute skill: weekly_report

Fires the weekly_report skill at 9 AM every Monday. The skill aggregates the week's data, generates a report, emails it to the team.

Monthly backup

0 0 1 * * Execute skill: backup_all

Fires the backup_all skill at midnight on the first of every month. The skill snapshots the agent directory, the skills directory, the memory database, uploads to cold storage.

Each of these is a single cron line that fires a multi-step skill. The cron is the trigger; the skill is the work. The 5-hour refresh window contains the day's chain with headroom.

Cron + 5-hour window, worked example

The host's morning pipeline, fitted to a 5-hour budget window:

00:00 - ai_research_pipeline (6-hour sweep)        # 30 prompts
06:00 - twitter_intelligence                       # 15 prompts
07:00 - daily_briefing                             # 25 prompts
07:30 - create_briefing_presentation               # 20 prompts
08:00 - send_to_discord                            # 5 prompts
12:00 - ai_research_pipeline (6-hour sweep)        # 30 prompts
18:00 - ai_research_pipeline (6-hour sweep)        # 30 prompts

Total prompts per 5-hour window:

  • 00:00–05:00 window: 30 (the sweep) = 30 prompts
  • 06:00–11:00 window: 15 + 25 + 20 + 5 = 65 prompts
  • 12:00–17:00 window: 30 prompts
  • 18:00–23:00 window: 30 prompts

Maximum: 65 prompts in a single 5-hour window (the 06:00–11:00 block). The starter tier's 100-prompt budget has 35 prompts of headroom for retries. The Max tier's 15,000-prompt budget has effectively unlimited headroom (258R3kzDRAQ, transcript).

The design rule: schedule the chain so the busiest 5-hour window is under the budget. If a single window busts the budget, break the chain into smaller pieces, or upgrade to a higher tier. The chain should never depend on crossing a refresh boundary.

Cron vs sub-agents vs skills

A note on overlap. Cron fires skills. Skills can spawn sub-agents. Sub-agents do work and return output. The three layers compose:

  • Cron is the trigger. "Run this skill at 7 AM every day."
  • Skill is the recipe. "Do the daily briefing: research, outline, slides, save, notify."
  • Sub-agent is the worker. "Spawn a Twitter research agent, a news research agent, a Reddit research agent, and a HN research agent; collect their outputs."

A cron job fires a skill; the skill spawns sub-agents; the sub-agents do the work. The 5-hour refresh window contains the cumulative cost. The 40% context threshold is checked at the skill level (the orchestrator's prompt), not the sub-agent level (each sub-agent has its own context).

The full chain, end-to-end:

0 7 * * *  →  daily_briefing skill  →  twitter_intelligence sub-agent
                                          web_news_scraping sub-agent
                                          documentation_updates sub-agent
                                          identify_trends sub-agent
                                          create_briefing_presentation sub-agent
                                          send_to_discord sub-agent

Each sub-agent is a worker; the skill is the orchestrator's playbook; the cron is the alarm clock. The 5-hour window is the budget that contains the whole performance.

Try it yourself

The hands-on goal for this subtopic: schedule a real cron job, verify it fires, and confirm it fits inside a 5-hour refresh window.

  1. Find your cron configuration. Ask the agent: "Show me my cron jobs." It will return the current list. If empty, you've never scheduled one.
  2. Pick a workflow to automate. A daily brief, a tweet scrape, a market check. The workflow should have a clear output and a clear success condition.
  3. Create the skill first. Use the methods from 6.2 to build the skill. Verify it works by running it manually. Don't schedule a cron for a skill that doesn't exist.
  4. Test the skill in a 2-minute window. "Create a cron job that runs in 2 minutes to test my [skill]." Watch the agent. Verify the output.
  5. Set the time zone. Ask: "What time zone are you using for cron jobs?" If wrong, fix the OpenClaw config and restart the service.
  6. Verify API keys. "Test my [provider] API key configuration for cron jobs." If the test fails, fix the key in every config location.
  7. Schedule the production cron. Once the test passes, schedule the real cron. Use the production time, not the 2-minute test.
  8. Calculate the budget. Sum the prompt cost of every cron job in the busiest 5-hour window. Confirm it fits under the tier's limit (100 prompts starter, 15,000 Max).
  9. Set up failure notifications. "Send email on failure. Send Discord notification on failure. Log detailed error information." You want to know the moment a cron breaks.
  10. Document the cron job. Add it to a registry: schedule, purpose, dependencies, notifications, owner. The host's pattern: a single markdown file that lists every cron job with its metadata (09-cron-jobs.md source).

Common pitfalls

  • Scheduling for 3 AM and hoping. The test window is 2 minutes, not "later tonight." If the cron is wrong, you want to know while you're awake.
  • Forgetting the time zone. The server may not be in your time zone. Verify the OpenClaw time zone matches your wall clock. A cron that fires at 2 AM your time is technically correct but practically useless.
  • Missing API keys in the cron environment. API keys have to be in every config location, not just ~/.bashrc. The cron shell reads from a different environment than your interactive shell.
  • Crossing the 5-hour refresh boundary. A 4-hour job followed by another job 30 minutes later resets at the boundary, and the second job starts from zero budget. Design the chain to fit in a single window.
  • Trusting "schedule for 2 minutes" tests without checking the output. The 2-minute test confirms the cron fires. It does not confirm the output is correct. Always verify the deliverable: the Discord post, the file on disk, the email in the inbox.
  • Skipping failure notifications. A cron that fails silently is a cron you don't know is broken. Set up Discord/email notifications for failures, and check them daily for the first week.
  • Polling too frequently. Hourly runs on news/social sources find fewer than 5 new items per cycle (14-subagent-blueprint.md source). The data is sparse; the API calls are wasted. Use 6-hour or daily intervals.
  • Batching everything into one job. A single cron that does research + analysis + presentation + delivery in one body is harder to debug than a chain of 4 jobs. The host's pattern: isolate failures by splitting the chain.
  • Forgetting the parallel-execution gotcha. Old OpenClaw versions had a bug where multiple cron jobs at the same time would cancel each other. The fix: update to the latest version. The host's check: "What version of OpenClaw am I running?" (09-cron-jobs.md source).
  • Letting cron jobs accumulate without review. A cron job that was useful 6 months ago may be obsolete. The host's monthly review: list every cron, check the output, retire the dead ones. A library of 30 cron jobs is harder to debug than a library of 8.

Sources

  • OpenClaw Cron Jobs EXPLAINED — referenced as the canonical cron walkthrough, see Course 9 for the full transcript and summary_content. The format breakdown, common patterns, time-zone gotcha, API-key gotcha, and testing protocol are all from the 09-cron-jobs.md source.
  • Is Minimax the Best AI Model for OpenClaw? — 3,219 views · video_id: 258R3kzDRAQ · cited: 5-hour refresh window, 100 prompts per 5 hours on Minimax coding plan starter tier, 15,000 on Max tier
  • Supabase query — SELECT video_id, title, views, has_transcript, has_summary, summary_content, summary_key_takeaways, summary_verdict FROM public.videos WHERE video_id = ANY(ARRAY['258R3kzDRAQ']); against project ttxdssgydwyurwwnjogq. The 5-hour refresh cadence and the 100/15,000 prompt tiers are transcript-sourced.