OpenClaw `HEARTBEAT.md` Example: Safe Defaults, Quiet Hours, and Real Templates

OpenClaw HEARTBEAT.md Example: Safe Defaults, Quiet Hours, and Real Templates

If you want a real HEARTBEAT.md OpenClaw example, start with this rule: keep the file small, strict, and biased toward silence unless something genuinely matters.

A good HEARTBEAT.md is not a second task manager and not a vague prompt that says "be helpful." It is a tiny operating contract for recurring checks, quiet-hour behavior, escalation thresholds, and the default HEARTBEAT_OK path.

This page stays in the file/template lane. If you need the broader subsystem explanation first, read The OpenClaw Heartbeat. If you are still deciding whether the job belongs in heartbeat at all, compare OpenClaw Cron vs Heartbeat.

What this note covers

• what to actually put in HEARTBEAT.md
• copyable starter templates
• how HEARTBEAT_OK should work
• when heartbeat should stay quiet
• when the job belongs in cron instead

What this note is based on

• real OpenClaw heartbeat behavior
• a live production HEARTBEAT.md pattern
• the broader source-backed note on OpenClaw heartbeat

This page is the file-level implementation lane: what to actually put in HEARTBEAT.md, how HEARTBEAT_OK should work, and how to avoid turning heartbeat into notification sludge.

Jump to

• The minimal safe-default example
• What belongs in HEARTBEAT.md
• A founder/operator example
• A low-noise variant
• How HEARTBEAT_OK works
• Heartbeat vs cron
• Quiet hours and notification hygiene
• Anti-patterns

The minimal safe-default HEARTBEAT.md example

Most people should start with something this small:

Check one or two recurring things that matter.
If something urgent or meaningfully new appears, send a short update.
If nothing needs attention, reply HEARTBEAT_OK.
Do not repeat old tasks. Keep quiet at night unless urgent.

Why this works:

• it gives heartbeat a narrow job
• it defines the silent default
• it prevents stale "helpful" chatter
• it leaves one clear exception for real urgency

If your first file is much longer than this, it is usually already drifting.

What belongs in HEARTBEAT.md

Use heartbeat for:

• recurring ambient checks
• batching multiple soft checks into one wake
• simple "only message if changed" logic
• quiet-hours behavior
• lightweight state-tracking reminders

Do not use heartbeat for:

• one-off reminders at an exact time
• giant wish lists
• vague prompts like "be proactive" with no thresholds
• repeated stale tasks copied forward forever
• heavy workflows that need clean isolation

The easiest way to make a bad heartbeat file is to treat it like a dumping ground for every idea you do not want to forget.

A founder/operator HEARTBEAT.md example

Once the minimal version is working, you can add a slightly richer operator pattern without losing discipline:

Read HEARTBEAT.md and follow it strictly.
Check email, calendar, and any configured notification sources.
If something urgent arrived, or an event is less than 2 hours away, send one compact update.
If nothing materially changed, reply HEARTBEAT_OK.
Stay quiet between 23:00 and 08:00 unless urgent.
Track last-check timestamps in a small state file.

This version is still narrow. It does not say "do anything useful you can think of." It names the surfaces, the escalation rule, the quiet window, and the silent path.

That is the difference between a useful HEARTBEAT.md OpenClaw setup and a noisy pseudo-autonomy prompt.

A low-noise variant for people who mostly want quiet

Some operators want heartbeat mainly as a background safety net. In that case, be even stricter:

Only check the highest-signal source.
Only send a message for urgency, deadlines, or a truly new blocker.
Never send routine "all clear" updates.
If nothing matters, reply HEARTBEAT_OK.
Always stay quiet at night unless urgent.

This is often better than the "ambitious" version. Heartbeat gets more valuable when it is boring in the good way: predictable, quiet, and hard to regret.

How HEARTBEAT_OK should work

HEARTBEAT_OK is not a cute magic word. It is an attention-respecting design pattern.

The point is simple:

• the heartbeat woke up
• the checks ran
• nothing crossed the threshold
• the system should preserve silence instead of manufacturing chatter

That matters because the wrong alternative is an endless stream of low-value pings:

• "nothing new"
• "just checking in"
• "all good so far"

Those messages teach you to ignore the system. HEARTBEAT_OK keeps the loop observable without forcing a social interruption every time the scheduler fires.

HEARTBEAT.md vs cron

The clean split looks like this:

Use heartbeat when:

• the task is periodic and soft-edged
• multiple checks can be batched together
• you only want output when something changed
• exact timing is not the main requirement

Use cron when:

• the task must happen at a specific time
• you want a one-off reminder
• the run should be isolated from the main conversation lane
• exact scheduling matters more than batching

Smell test:

• if the instruction sounds like "at 9:00 tomorrow", use cron
• if it sounds like "periodically check whether...", use heartbeat

If your HEARTBEAT.md starts carrying lots of exact-time instructions, it is trying to do cron's job.

For the deeper comparison, read OpenClaw Cron vs Heartbeat.

Quiet hours, urgency, and notification hygiene

A production-grade heartbeat file should encode social behavior, not just technical behavior.

The most important questions are:

• when should the system stay quiet?
• what actually counts as urgent?
• when is a proactive message justified?

A solid default is:

• quiet late at night unless something is urgent
• no repeated pings for the same unchanged condition
• no routine messages when no decision is needed
• escalate only when there is a real deadline, blocker, or meaningful change

The fastest way to ruin heartbeat is to make it socially noisy.

Anti-patterns that turn HEARTBEAT.md into sludge

1. The giant checklist

A long file with ten different check families and no prioritization burns attention and tokens without giving a clean decision path.

2. The vague autonomy spell

"Be proactive and useful" sounds powerful but leaves the system guessing. Good files define thresholds.

3. Exact reminders stuffed into heartbeat

That creates fuzzy timing and duplicated logic. Use cron for exact reminders.

4. Repeating stale tasks forever

If the file keeps dragging old work forward without a freshness rule, heartbeat becomes a nag loop.

5. No quiet-hours rule

Without a silence boundary, the agent may behave technically correctly and still feel socially broken.

How to evolve HEARTBEAT.md without overbuilding it

Start tiny.

Then add one thing at a time:

1. one recurring check
2. one escalation threshold
3. one quiet-hours rule
4. one small state-tracking rule if needed

Do not jump from zero to a miniature operating system.

The right way to grow the file is by pruning and tightening, not by stacking more cleverness on top.

A good HEARTBEAT.md should feel more like a compact contract than a brainstorm document.

What to read next

If you want the broader subsystem explanation, read:

• OpenClaw heartbeat and how proactive loops work

If you want the scheduler choice, read:

• OpenClaw Cron vs Heartbeat

If you want the broader architecture map, read:

• I read OpenClaw's source code

If you want the practical operator setup lane, read:

• OpenClaw tutorial: Mac mini setup

Conclusion

The best HEARTBEAT.md OpenClaw file is not the smartest-looking one. It is the one that preserves signal.

Keep it small. Keep it explicit. Keep it quiet by default. Use HEARTBEAT_OK as the silent success path. Use cron when timing precision matters.

That is how heartbeat stays useful instead of becoming ambient spam.