OpenClaw Heartbeat Setup: How to Build Useful Daily Checks

If you want OpenClaw to check on things proactively without turning into a noisy bot, the right move is to set up heartbeat. The practical answer is simple: write a short HEARTBEAT.md file with a few high-value checks, clear rules for when to report, and clear rules for when to stay quiet. That is what makes heartbeat useful.

A lot of people get this backwards at first. They treat heartbeat like a place to dump every smart idea they have. Then the agent starts checking too much, talking too often, and burning time on low-value updates. A good heartbeat setup is smaller than most people expect.

This tutorial walks through the full setup in plain English. By the end, you should know how to decide what belongs in HEARTBEAT.md, how to write it, how to test it, and how to keep it from becoming spam.

If you want the broader OpenClaw context first, start with what OpenClaw is and workspace files. If you want the higher-level operating advice behind this tutorial, read OpenClaw memory best practices and AI agent guardrails best practices for OpenClaw.

What heartbeat actually does

Heartbeat is a periodic check. It gives the agent a chance to look around, run a small checklist, and decide whether anything deserves your attention.

That sounds simple because it is.

The point of heartbeat is not to create a full autonomous operator. The point is to avoid the constant manual sweep most people do anyway:

• check whether something urgent came in
• check what is due soon
• check whether a follow-up is slipping
• check whether a routine problem needs attention

Heartbeat handles that layer well when the rules are tight.

When heartbeat is a good fit

Heartbeat works best when the job needs light judgment and does not require exact timing.

Good heartbeat use cases include:

• upcoming calendar checks
• urgent unread message checks
• stale follow-up checks
• daily project context summaries
• simple operational awareness tasks

Heartbeat is not the right tool when timing must be exact. If the task is "remind me at exactly 4 PM," use cron instead. If the task is "check every so often whether anything now needs attention," heartbeat is the better fit.

If you want to build both layers well, this post pairs nicely with the tutorial on OpenClaw cron setup.

Step 1: pick only 2 to 5 checks

This is the most important step.

Do not start with ten checks. Do not start with every source you might someday care about. Start with the few checks that would genuinely save you from dropped balls.

A good first list usually looks something like this:

• calendar events in the next few hours
• urgent unread messages
• follow-ups older than 24 hours
• failed automation or workflow alerts

That is enough for many setups.

A bad first list usually looks like this:

• inbox
• calendar
• mentions
• competitor news
• weather
• tasks
• social notifications
• server health
• leads
• random strategic scanning

That is not a heartbeat. That is a second job.

When choosing checks, ask:

• does missing this create real pain?
• does it come up often enough to justify repetition?
• can the agent evaluate it quickly?
• would I be glad to hear about it, or annoyed?

If you are not sure, leave it out for week one.

Step 2: define report rules before you define wording

Most noisy heartbeat setups fail here.

People think first about how they want the output to sound. That matters, but it is secondary. First decide what should trigger a report at all.

Here is a clean pattern:

Only report if:
- something is urgent
- a meeting is coming up soon and needs prep
- a follow-up is likely to be missed today
- an automation failed and probably needs intervention

That small section does a lot of work. It tells the agent that a check is not automatically a message.

This is the idea to keep in your head: heartbeat exists to notice, not to speak. Speaking should happen only when the result is actually useful.

Step 3: add stop conditions and quiet hours

A heartbeat needs permission to stay silent.

Without that, the agent starts trying to be helpful on every cycle. That is where most people begin to hate proactive automation.

Good stop conditions include:

• if nothing changed, reply HEARTBEAT_OK
• do not report low-priority items
• do not repeat the same issue constantly
• do not send routine updates overnight

Quiet hours matter more than people think. Even if the agent is technically right, a midnight message about a non-urgent item feels intrusive.

A practical quiet-hours block might look like this:

When to stay quiet:
- between 11 PM and 8 AM unless urgent
- when nothing changed since the last check
- when only low-priority items are present

That is enough to make the system feel more human.

Step 4: write the file like a checklist, not an essay

Your HEARTBEAT.md file should be short, scannable, and operational.

A good starting version looks like this:

# HEARTBEAT.md

Purpose: keep me aware of important operational changes without spamming me.

Checks:
1. Calendar events in the next 4 hours
2. Urgent unread messages
3. Follow-ups older than 24 hours
4. Failed automations that need review

Only report if:
- something needs action today
- a meeting is coming up soon
- an urgent item is unanswered
- a failure probably needs intervention

When to stay quiet:
- nothing changed since the last check
- only low-priority items are present
- between 11 PM and 8 AM unless urgent

Output style:
- one short summary line
- 1 to 3 bullets max
- say what needs action now

If nothing needs attention, reply HEARTBEAT_OK.

That is already enough to run a useful heartbeat.

Step 5: test it in a low-risk way first

Do not assume your first version is right.

Run it for a few days and look for patterns:

• Was it too chatty?
• Was it too quiet?
• Did it surface the wrong things?
• Did it miss the items you actually care about?
• Did it repeat itself too much?

Then tune the file.

Most heartbeat improvement comes from subtraction. Remove vague checks. Tighten report rules. Add better stop conditions. Resist the urge to add complexity too early.

Step 6: track state if repetition becomes a problem

Some heartbeat setups benefit from a tiny state file.

You do not need this on day one, but it helps when the agent keeps surfacing the same item without enough context about when it was last checked or last reported.

A lightweight state file might look like this:

{
  "lastChecks": {
    "calendar": 1775344800,
    "messages": 1775344800,
    "followups": 1775344800
  }
}

The point is not to build a huge state system. The point is to help the agent avoid repetitive reporting.

Good first heartbeat examples

Here are three solid first heartbeat use cases.

Founder or operator

• next meetings
• urgent inbound messages
• stale follow-ups

Small team lead

• deadlines due soon
• blocked tasks
• missing responses in team workflows

Content or marketing workflow

• draft awaiting review
• publishing deadline within 24 hours
• campaign issue that needs attention

All three are small, clear, and easy to judge.

Common heartbeat mistakes

Mistake 1: using heartbeat for exact reminders

If timing must be exact, use cron. Heartbeat is meant for periodic awareness, not precision reminders.

Mistake 2: stuffing HEARTBEAT.md with every idea

A short file beats a clever file. If the checklist keeps growing, the heartbeat becomes expensive and noisy.

Mistake 3: no quiet-hours rule

Without a quiet-hours rule, even a useful system can feel rude.

Mistake 4: no permission to say nothing

The best heartbeat outcome is often no message. That is a feature, not a failure.

What a finished setup should feel like

When heartbeat is working, you should feel two things at once:

• fewer things fall through the cracks
• the agent is not constantly interrupting you

That is the bar.

If you are getting more awareness but also more irritation, the file still needs work.

My recommendation

Start tiny.

If you are setting up heartbeat today, use only these three checks:

• upcoming calendar events
• urgent unread messages
• stale follow-ups

Run that for a week. Then improve it based on real noise, not imagined edge cases.

If you want the official references, review the OpenClaw docs and the OpenClaw GitHub repository. Then compare your heartbeat file against one simple question: would this make my week smoother, or would it just make my agent busier?

FAQ

What is heartbeat in OpenClaw?

Heartbeat is a periodic check that lets the agent read HEARTBEAT.md, run a short checklist, and report only when something needs attention.

What should go in HEARTBEAT.md?

A small list of high-value checks, report rules, stop conditions, quiet-hours rules, and a short output format.

How many checks should I start with?

Usually 2 to 5. Fewer is better at the beginning.

What is the difference between heartbeat and cron?

Heartbeat is better for periodic awareness and judgment-based checks. Cron is better for exact reminders and fixed-time workflows.

How do I make heartbeat less noisy?

Tighten the report rules, add stop conditions, and give the agent permission to stay quiet when nothing important changed.