Subtopic 6.3 covered cron syntax and the 5-hour refresh window. Subtopic 6.4 is the pattern that makes cron useful: the chain. A single cron job is a single trigger. A chain of cron jobs is a workflow — four triggers, four skills, one finished deliverable in your Discord at 8 AM.

The channel's morning pipeline is the canonical example: 6 AM Twitter scrape, 7 AM daily brief, 7:30 AM slides, 8 AM Discord delivery. Each step is its own cron job, firing its own skill, depending on the output of the previous step. The chain runs in 2 hours, fits inside a 5-hour refresh window, and produces a finished briefing without any human in the loop.

This article walks through the chain end-to-end, the dependency graph, the failure isolation, the parallel-execution option, and the worked example from the channel's own bot. The 5-hour refresh window is the heartbeat; the chain is the rhythm.

What you'll learn

  • The canonical chain is 4 jobs: 0 6 * * * (Twitter scrape), 0 7 * * * (daily brief), 30 7 * * * (slides), 0 8 * * * (Discord delivery) (09-cron-jobs.md source). Each job is a single cron line that fires one skill.
  • Chained jobs isolate failures: if the 6 AM Twitter scrape fails, the 7 AM brief can still run with stale data (or skip the Twitter section), and you know exactly which step broke (09-cron-jobs.md source).
  • The 6 AM and 7 AM jobs can run in parallel if they don't depend on each other. The 7:30 AM slides depend on the 7 AM brief; the 8 AM Discord post depends on the 7:30 AM slides. The dependency graph is a chain, not a tree.
  • The whole pipeline fits in 2 hours (6 AM to 8 AM) with 3 hours of headroom inside a 5-hour refresh window. The cumulative prompt cost is ~65 prompts on a Minimax coding plan starter tier, well under the 100-prompt budget (258R3kzDRAQ, transcript).
  • The channel's own bot runs this chain every morning. The 8:00 AM cron fires the daily_briefing skill, which has been previously chained to the presentation skill — "one prompt triggers both research and slides" (Zkw8jIDzspc, transcript).
  • The chain can be tested step-by-step: schedule the 6 AM job for 2 minutes from now, verify, then schedule the 7 AM job 1 minute after that, verify, and so on. Each step is tested in isolation before the next is added.

The canonical morning chain

┌─────────────────────────────────────────────────────┐
│  5-Hour Refresh Window: 06:00 – 11:00               │
│                                                     │
│  06:00  ─→  twitter_intelligence skill              │
│              • Scrape monitored accounts             │
│              • Save to memory/twitter/YYYY-MM-DD.json│
│              • Cost: ~15 prompts                    │
│                                                     │
│  07:00  ─→  daily_briefing skill                    │
│              • Read Twitter JSON from 06:00         │
│              • Run web_news_scraping in parallel    │
│              • Run documentation_updates in parallel│
│              • Run identify_trends on all results   │
│              • Run gap_analysis on all results      │
│              • Cost: ~25 prompts                    │
│                                                     │
│  07:30  ─→  create_briefing_presentation skill      │
│              • Read daily brief from 07:00          │
│              • Generate HTML deck with SVG graphics │
│              • Save to ~/presentations/daily/       │
│              • Cost: ~20 prompts                    │
│                                                     │
│  08:00  ─→  send_to_discord skill                   │
│              • Read deck from 07:30                 │
│              • Post link + summary to #daily-brief  │
│              • Cost: ~5 prompts                     │
│                                                     │
│  Total: ~65 prompts in 2 hours (35 prompts headroom)│
└─────────────────────────────────────────────────────┘

The chain runs in 2 hours (6 AM to 8 AM) and fits inside a single 5-hour refresh window (06:00 to 11:00). The cumulative prompt cost is ~65, well under the 100-prompt starter tier budget (258R3kzDRAQ, transcript). The Max tier's 15,000-prompt budget has effectively unlimited headroom for retries.

Why chain instead of one job

A single cron that does the whole pipeline in one body is technically possible. The host's pattern is to split anyway (09-cron-jobs.md source):

  • Isolate failures. If step 2 (the brief) fails, you know step 2 is broken. If the chain is one job, you know "the job" is broken and you have to dig through 4 sub-steps to find the culprit.
  • Easier debugging. Each job has its own logs, its own output, its own success/failure status. You can run job 2 manually with stale data from job 1, even if job 1 hasn't run today.
  • Manual overrides. If you want to re-run the brief without re-scraping Twitter, you can fire job 2 manually. If the chain is one job, you have to re-run everything.
  • Budget visibility. A chain of 4 jobs gives you 4 budget events. A single job gives you 1 budget event. If the budget is tight, knowing which step is expensive is the difference between optimising and guessing.

The cost of the chain is 4 cron lines instead of 1. The benefit is observability and control.

The dependency graph

The 4-job chain has a clear dependency graph:

twitter_intelligence (06:00)
        │
        ▼
daily_briefing (07:00)  ──→  web_news_scraping (parallel)
                          ──→  documentation_updates (parallel)
                          ──→  identify_trends (sequential)
                          ──→  gap_analysis (sequential)
        │
        ▼
create_briefing_presentation (07:30)
        │
        ▼
send_to_discord (08:00)

The brief depends on the Twitter scrape. The slides depend on the brief. The Discord post depends on the slides. The brief also depends on the parallel web and documentation jobs, but those are sub-agents spawned by the brief itself, not separate cron jobs.

The pattern: a cron chain is a sequence of dependencies, and each step can spawn its own sub-agents internally. The chain is the skeleton; the sub-agents are the muscle.

The channel's own morning pipeline

The host's bot runs this exact chain. From the "build your agent right" video (Zkw8jIDzspc, transcript):

"The daily briefing runs at 8:00 AM sharp, picks the morning deliberately so the news is fresh, and chains to the presentation skill — one prompt ('make a new presentation about what's new in the latest open claw 2024 and include points from our last presentation') triggers both research and slide output."

The "one prompt" is the 8:00 AM cron. The "research and slide output" are the daily_briefing and create_briefing_presentation skills chained together. The host's framing: the user types one message, the bot does the rest. The cron version is the same chain, but the trigger is the schedule, not the user.

The host's chain has been refined over months of daily runs. The 8:00 AM cron was originally at 7:00 AM; the host moved it to 8:00 because the news cycle is fresher at 8 (Zkw8jIDzspc, transcript). The 7:00 AM brief was originally at 6:00 AM; the host moved it later because the Twitter scrape at 6:00 is sometimes incomplete (rate limits, slow API). The 7:30 AM slides slot is a deliberate buffer: if the brief is late, the slides still have 30 minutes to catch up before the 8:00 AM Discord post.

The chain is not optimal in the abstract. It's optimal for the host's data sources, refresh windows, and waking hours. The pattern — schedule the chain to fit your data, not the other way around — is the generalisable rule.

Parallel execution within a step

Some steps can run in parallel. The brief at 7:00 AM is the most parallel step in the chain: it depends on Twitter, web, and documentation, none of which depend on each other. The skill spawns three sub-agents, collects their outputs, then runs identify_trends and gap_analysis sequentially on the merged result (09-cron-jobs.md source).

daily_briefing (07:00)
        │
        ├──→ twitter_intelligence sub-agent (read pre-scraped JSON)
        ├──→ web_news_scraping sub-agent (live scrape)
        ├──→ documentation_updates sub-agent (live scrape)
        │
        ▼
        identify_trends sub-agent (sequential, on merged results)
        │
        ▼
        gap_analysis sub-agent (sequential, on trend output)

The three scrapers run in parallel because they hit different sources and have no inter-dependencies. The two analysis sub-agents run sequentially because they depend on the merged input.

The cron level: only one job fires at 7:00 AM. The parallelism is inside the skill, not at the cron layer. The host's note: "Latest OpenClaw version handles parallel cron jobs correctly (older versions had conflicts)" (09-cron-jobs.md source). If you're on an older version, the parallelism has to live inside the skill, not at the cron layer.

The "old version had conflicts" bug

Pre-3.7 OpenClaw had a bug where two cron jobs at the same time would cancel each other. Symptom: Job 1 starts at 6:00 AM, Job 2 starts at 6:05 AM, Job 1 gets cancelled (09-cron-jobs.md source). The fix: update to the latest OpenClaw version. The check: "What version of OpenClaw am I running?" If pre-3.7, upgrade.

The channel's earlier rule: if you have multiple jobs at the same time, schedule them as sub-agents inside a single skill. The cron fires once, the skill spawns the workers, the workers run in parallel without the cancellation bug. The trade-off: less visibility (one job in the cron list, four workers in the logs).

Failure isolation and recovery

The chain's design property: a failure at step 2 doesn't break steps 3 and 4. The brief fails; the slides can still run on whatever output the brief managed to produce (or the slides can be skipped). The Discord post can post a "brief failed" notification instead of a finished deck. The 8:00 AM cron is independent of the 7:30 AM cron's success.

Failure scenarios

The 4 failure modes the chain design handles (09-cron-jobs.md source):

  • Step 1 (Twitter) fails. The 7:00 AM brief can run with stale Twitter data (yesterday's scrape) or with Twitter skipped. The brief's quality drops; the chain doesn't break.
  • Step 2 (brief) fails. The 7:30 AM slides have no input; they can either skip (no deck) or generate a "no data" placeholder. The 8:00 AM Discord post can announce the failure instead of posting a deck.
  • Step 3 (slides) fails. The 8:00 AM Discord post has no deck to link; it can post a text-only summary of whatever the brief produced.
  • Step 4 (Discord) fails. The chain is "complete" except for delivery. The deck is on disk; you can post it manually. The cron job should fire a failure notification (email, secondary Discord channel) so you know.

The chain's design rule: each step's success is logged, each step's failure is caught, and the next step is told whether to proceed or skip. The failure notification is independent of the chain: it goes to a separate channel so the chain's own Discord post doesn't get eaten by the failure message.

Manual overrides

The chain supports manual overrides for every step. The pattern (09-cron-jobs.md source):

  • "Run the daily briefing cron job now." Fires the 7:00 AM job manually. Useful when you want a fresh brief mid-day.
  • "Re-run the slides with the new brief." Fires the 7:30 AM job manually, regenerating the deck from the latest brief.
  • "Post the deck to Discord." Fires the 8:00 AM job manually, posting whatever's on disk.

Each override fires one job, not the whole chain. The chain's value is the scheduled run; the manual override is the safety valve.

The 5-hour refresh window, again

The chain is designed to fit a 5-hour window. The morning chain runs from 6 AM to 8 AM, occupying 2 hours of the 06:00–11:00 refresh window. The headroom is 3 hours, which is enough for one full retry of any step (each step is <30 minutes) plus the 6-hour research sweep at 12:00 PM.

The 6-hour sweep (0 */6 * * *) fires at 00:00, 06:00, 12:00, 18:00. The 00:00 sweep is in the 00:00–05:00 window. The 06:00 sweep is in the 06:00–11:00 window, parallel to the morning chain. The 12:00 sweep is in the 12:00–17:00 window. The 18:00 sweep is in the 18:00–23:00 window.

Each sweep costs ~30 prompts. The morning chain costs ~65 prompts. The cumulative cost per 5-hour window:

  • 00:00–05:00: 30 prompts (the sweep)
  • 06:00–11:00: 65 (chain) + 30 (sweep) = 95 prompts — under the 100-prompt starter budget
  • 12:00–17:00: 30 prompts
  • 18:00–23:00: 30 prompts

The tightest window is 06:00–11:00 at 95 prompts. The host's design rule: keep the tightest window under the budget. The 100-prompt starter tier has 5 prompts of headroom; the 15,000-prompt Max tier has effectively unlimited headroom. If you need more headroom, upgrade the tier or move the sweep to a different cadence.

Variations on the chain

The 4-job chain is a starting point. Common variations:

3-job minimal chain (no slides)

06:00 - twitter_intelligence
07:00 - daily_briefing (text-only)
08:00 - send_to_discord (text-only)

Skip the slides step. The brief is a markdown summary, not an HTML deck. Lower prompt cost, lower visual quality, faster to iterate.

5-job chain with weekly rollup

06:00 - twitter_intelligence
07:00 - daily_briefing
07:30 - create_briefing_presentation
08:00 - send_to_discord
09:00 * * 1 - weekly_rollup (Mondays only)

Add a Monday-only job that aggregates the week's briefs into a rollup report. Costs an extra ~15 prompts on Mondays only.

6-job chain with competitive intelligence

06:00 - twitter_intelligence
07:00 - daily_briefing
07:30 - create_briefing_presentation
08:00 - send_to_discord
*/6 * * * * - ai_research_pipeline (6-hour sweep)
0 0 * * 0 - weekly_competitive_report (Sundays)

Add the 6-hour sweep and a weekly competitive report. The sweep runs every 6 hours; the weekly report fires on Sundays. The cumulative cost stays under budget.

Each variation fits the same pattern: a chain of dependent skills, fired by cron, contained in a 5-hour budget window.

Try it yourself

The hands-on goal for this subtopic: build the 4-job morning chain on your own agent, test it step by step, and verify it runs end-to-end.

  1. Pick the 4 skills. twitter_intelligence, daily_briefing, create_briefing_presentation, send_to_discord. Use 6.2 to build each one. Verify each works manually.
  2. Schedule the 6:00 AM job first. "Create a cron job that runs in 2 minutes to test my twitter_intelligence skill." Watch it fire. Verify the JSON is on disk.
  3. Schedule the 7:00 AM job. Set it for 2 minutes after the test run completes. "Create a cron job that runs at [time] to execute daily_briefing." Verify the brief is on disk.
  4. Schedule the 7:30 AM job. Same pattern. Verify the deck is on disk.
  5. Schedule the 8:00 AM job. Same pattern. Verify the Discord post lands.
  6. Check the budget. Ask the agent: "How many prompts have I used in the last 5 hours?" Confirm the cumulative cost is under 100.
  7. Schedule the production chain. Once all 4 tests pass, schedule the real chain for 6 AM, 7 AM, 7:30 AM, 8 AM.
  8. Wait for the morning. Open Discord at 8:01 AM. The deck should be there. If it's not, check the failure notification channel.
  9. Iterate. The first morning's chain rarely matches the spec. Update the skills based on what was wrong, re-test, and re-schedule.
  10. Add failure notifications. "Send email on failure. Send Discord notification to #cron-failures on failure." You want to know the moment a step breaks.

Common pitfalls

  • Putting the whole pipeline in one job. A single cron that does 4 steps in one body is hard to debug. Split into 4 jobs. The cost is 4 cron lines; the benefit is observability.
  • Crossing the 5-hour refresh boundary. Schedule the chain to fit in a single 5-hour window. A 4-hour job followed by another job 30 minutes later resets at the boundary.
  • Skipping the test phase. Test each job in a 2-minute window before scheduling the production chain. A failure at 3 AM is much worse than a failure at 2:01 PM.
  • Trusting the "test passed" without checking the output. A 2-minute test confirms the cron fires. It does not confirm the output is correct. Verify the deliverable: the JSON on disk, the deck on disk, the Discord post.
  • Pre-3.7 OpenClaw with parallel cron jobs. If you're on an older version, multiple jobs at the same time cancel each other. Update OpenClaw, or put the parallelism inside the skill.
  • No failure notifications. A cron that fails silently is a cron you don't know is broken. Set up Discord/email notifications for failures on every job in the chain.
  • No manual override path. "Run the daily briefing cron job now" should work for every job in the chain. If the manual override is broken, the chain is fragile.
  • Busting the budget on retries. A 4-job chain that retries each step on failure can double the prompt cost. If the budget is tight, don't auto-retry. Let the failure notification fire, fix manually, re-run.
  • Forgetting the time zone. The chain runs in the server's time zone. A 6 AM cron in UTC is 1 AM EST. Verify the time zone when you install the chain.
  • Skipping the dependency check. The brief depends on the Twitter scrape. If the brief fires before the Twitter scrape completes, it runs on stale data. Schedule the dependent jobs with enough buffer (the host's 1-hour gap between 6 AM and 7 AM is the buffer).
  • Letting the chain accumulate technical debt. A 4-job chain that was tuned 6 months ago may be stale. The host's monthly review: list every cron, check the output, retire the dead ones. The morning chain is the most valuable cron job you have — review it monthly.

Sources

  • OpenClaw Cron Jobs EXPLAINED — referenced as the canonical cron walkthrough, see Course 9 for the full transcript and summary_content. The 4-job chain pattern, dependency graph, failure isolation, and parallel execution notes are all from the 09-cron-jobs.md source.
  • How to Build Your OpenClaw AI Agent the RIGHT Way — 2,690 views · video_id: Zkw8jIDzspc · cited: 8:00 AM daily briefing, "one prompt triggers both research and slide output" chaining, "picks the morning deliberately so the news is fresh"
  • Is Minimax the Best AI Model for OpenClaw? — 3,219 views · video_id: 258R3kzDRAQ · cited: 5-hour refresh window, 100/15,000 prompt tiers
  • 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['Zkw8jIDzspc','258R3kzDRAQ']); against project ttxdssgydwyurwwnjogq. Both videos have has_transcript = true and has_summary = true as of 2026-06-18. The 8:00 AM cron and the one-prompt chain are transcript-sourced from Zkw8jIDzspc; the 5-hour refresh cadence is transcript-sourced from 258R3kzDRAQ.