Heartbeats in OpenClaw: Cheap Checks First, Models Only When You Need Them

I used to think “heartbeat” meant “run the assistant every X minutes.” It doesn’t.

In OpenClaw, a heartbeat is just a regular pulse where your agent checks a short checklist and decides one of two things:

• Nothing important changed → reply HEARTBEAT_OK
• Something needs attention → send a short alert (and maybe do deeper work)

This post shows the approach I’m using now:

• do rule-based checks first (fast, deterministic, basically free)
• only call a model when there’s actual signal (summaries, decisions, or messy human context)

The core idea: a heartbeat is a gate, not a workflow

Think of a heartbeat as a gatekeeper.

A good heartbeat answers questions like:

• Did anything break? (CI failing, errors, deploy alarms)
• Did anything change? (new PR, new task queued, new email from a customer)
• Is anything time-sensitive? (calendar event in <2 hours, expiring cert)

Anything more is noise.

You usually don’t need a model for that

Most heartbeat logic is not “reasoning.” It’s just checking state.

Examples that don’t need an LLM:

• is the repo dirty?
• are there open PRs?
• did the agent queue grow?
• did a job fail?
• did Slack/WhatsApp disconnect?

A practical pattern: cheap mode first

Run a lightweight script first. It outputs either:

• HEARTBEAT_OK
• or HEARTBEAT_ALERT + bullet list of what changed

That gives you the best of both worlds:

• $0 heartbeats most of the time
• still get a clean human summary when something real happens

When should you involve a model?

A model is worth it when the output benefits from language understanding:

• summarising multiple alerts into one message
• deciding what to do first when several things changed at once
• writing a “brief” that a human actually wants to read
• turning raw logs into a short action plan

• run cheap checks
• if alert → use a small model (e.g. Claude Haiku) to summarise + recommend next actions

Tuning heartbeat frequency: faster isn’t always better

Heartbeat schedules are like monitoring: you want fast enough to catch the important stuff, but not so frequent that it turns into spam (or cost creep).

Short intervals (e.g. every 5 minutes)

• high-velocity shipping (lots of PRs / CI runs)
• active incident response
• anything with a “respond now” requirement

• cost, if an LLM runs every time
• notification fatigue (“another alert… for nothing”)
• wasted compute / API calls

Longer intervals (e.g. every 30–60 minutes)

• most solo founder work
• “keep an eye on it” workflows
• staying informed without interruptions

• you’ll learn about failures later
• some tasks won’t feel “real-time”

A simple rule of thumb

• If you’re actively shipping: 5–15 minutes
• If you’re in build mode but stable: 30 minutes
• If you’re just keeping watch: 60–120 minutes

The takeaway

If you’re using OpenClaw (or any agent system):

• Make heartbeats cheap and deterministic
• Treat the model as an escalation layer, not the default
• Tune frequency so you get signal, not noise