OpenClaw Cron Jobs & Scheduling Patterns

How HEARTBEAT.md scheduling works

Your agent polls HEARTBEAT.md on a regular interval. When it reads a timing instruction like "Every weekday at 9am," it checks whether that time has passed since the last run. If it has, it executes the steps below it.

You write schedules in plain English. No cron syntax. No configuration files. Just describe when you want something to happen and what should happen.

Basic: a single daily task

The simplest HEARTBEAT.md is one schedule with a few steps. This runs every weekday morning:

Every weekday at 9am:
1. Check inbox for urgent emails
2. Summarize calendar for today
3. Send morning briefing to Telegram

This pattern is used by the Morning Briefing and Email Triage Bot templates.

Advanced: multiple schedules in one file

You can define multiple timing blocks in a single HEARTBEAT.md. Each block runs independently. This is how monitoring workflows combine frequent checks with periodic reports:

Every 30 minutes:
1. Check API health endpoints
2. If any endpoint returns non-200, send alert immediately
3. Log response times to Google Sheet

Every weekday at 9am:
4. Compile overnight API health report
5. Include: uptime %, average response time, any incidents
6. Send report to #ops channel

Every Friday at 5pm:
7. Generate weekly reliability report
8. Compare this week vs last week
9. Flag any degradation trends
10. Send to #ops and email to team lead

Conditional logic in schedules

Because your agent reads HEARTBEAT.md as instructions (not as a config file), you can include conditional logic. The agent decides what to do based on what it finds:

Every weekday at 8am:
1. Check GitHub for PRs opened in the last 24 hours
2. For each PR:
   a. If it has no reviewers assigned, assign based on CODEOWNERS
   b. If it has been open for more than 48 hours with no review, ping the reviewer
   c. If CI is failing, comment with the error summary
3. Skip PRs marked as draft

Every 2 hours during business hours (9am-6pm):
4. Check for PRs that were approved but not merged
5. If approved PR has no merge conflicts, comment "Ready to merge"
6. If approved PR has conflicts, comment with conflict details

Cost optimization

Frequent schedules can get expensive if every run processes a lot of tokens. The trick is to structure your HEARTBEAT.md so most runs are cheap. Only do expensive work when there is something to act on.

# Cost-optimized: use conditions to skip unnecessary work

Every 15 minutes:
1. Quick health check: ping https://api.example.com/health
2. ONLY if health check fails:
   a. Run full diagnostic (check each endpoint individually)
   b. Collect error logs from the last 15 minutes
   c. Send detailed alert with diagnosis
3. If health check passes: do nothing (save tokens)

# This pattern costs ~$0.02/day instead of ~$0.50/day
# because most runs are a single API call with no LLM processing

Use Clawback to estimate costs before enabling a high-frequency schedule.

Common scheduling patterns

Templates with scheduling

These runbooks use HEARTBEAT.md scheduling patterns you can learn from: