the feature quietly draining your openclaw stack

why heartbeat becomes leverage for some people and silent cost for everyone else, plus the calm starter pack i’d use first

heartbeat is one of the easiest openclaw features to misread because it looks like free automation. it isn’t. it’s a recurring agent turn. use it well and it becomes a quiet monitoring loop. use it badly and it becomes background noise, silent spend, and one more thing you stop believing in.

heartbeat is not there to make openclaw feel alive.

it’s there to notice drift before you do.

the second you treat heartbeat like a second brain, you start stuffing it with too much context, too many jobs, and too much trust. then the feature that should’ve made your stack calmer starts acting like a tiny recurring bill with opinions.

what heartbeat is actually for

the docs are much narrower than a lot of people assume.

heartbeat runs periodic agent turns in the main session. the default cadence is 30 minutes, or 1 hour when anthropic oauth or setup-token auth is detected. the default guidance is to read heartbeat.md if it exists and reply heartbeat_ok if nothing needs attention. the default delivery target starts at target: “none” unless you change it.

that should immediately change how you think about it.

heartbeat is not your exact-time scheduler.

heartbeat is not your deep research runner.

heartbeat is not the place to ask for a mini employee every 30 minutes.

the split is cleaner than most people make it.

heartbeat is for periodic, context-aware checks that batch well together.

cron (openclaw’s exact-time scheduler for isolated tasks) is for exact timing, reminders at a sharp time, or isolated tasks that should not lean on the main conversation.

if timing matters, use cron.

if awareness matters, heartbeat is usually the better fit.

the most useful mental model is this.

watch. check. escalate.

watch means look at a surface that changes.

check means compare it to a condition, threshold, or expectation.

escalate means speak up only when the difference matters.

a solo founder running a five-integration PA stack — gmail, google calendar, slack, notion, transcription — does not need heartbeat to be “smart.”

they need it to notice a few recurring surfaces without turning the stack into chaos.

in that setup:

a good heartbeat

• checks the next two hours of calendar

• surfaces inbox threads that need human input

• flags one blocked task

a bad heartbeat

• tries to summarize the web

• writes strategy memos

• saves memory automatically

• messages multiple channels every half hour

the first version becomes leverage.

the second version becomes chaos.

copy this first

here’s the smallest heartbeat setup i’d start with before trying anything more ambitious.

three pieces:

• the instruction file

• the config

• two commands to confirm it loaded

step 1: create your heartbeat.md file

in your openclaw project folder, create a new file called heartbeat.md.

if you’re not sure where that is, run:

openclaw config get project.path

paste this into the file and save it:

check inbox for messages that need me in the next 2 hours.

check calendar for conflicts or prep needed.

check pending tasks that are overdue or blocked.

if nothing matters, reply heartbeat_ok.

if something matters, send one short alert with:

- what changed

- why it matters

- the next action i should take

that’s the bare minimum. it gives heartbeat a job without overloading it.

if you have specific integrations connected like gmail, google calendar, slack, notion » make those explicit.

heartbeat performs better when it knows exactly where to look:

check gmail for unread threads that need a reply from me in the next 2 hours.

check google calendar for meetings in the next 2 hours that need prep or have conflicts.

check notion for tasks marked overdue or blocked.

if nothing matters, reply heartbeat_ok.

if something matters, send one short slack alert with:

- what changed

- why it matters

- the one action i should take

swap in whichever tools you actually have connected.

a heartbeat that knows its tools is faster and cheaper than one guessing at them.

step 2: add this to your openclaw config file

your config file is called openclaw.yaml and lives in your project root.

add the heartbeat block under agents: defaults:.

before you paste:

change america/new_york to your timezone.

agents:

defaults:

heartbeat:

every: “60m”

model: “claude-haiku-3-5-20251001” # verify this matches your version

target: “none”

lightcontext: true

isolatedsession: true

activehours:

start: “08:00”

end: “20:00”

timezone: “america/new_york”

the model line matters.

heartbeat does not need your most capable model.

haiku-class models handle awareness checks cleanly at a fraction of the cost.

to verify available models:

openclaw models list

step 3: confirm it loaded

open your terminal.

run:

openclaw config get agents.defaults.heartbeat

openclaw system heartbeat last

the first confirms config.

the second confirms execution.

if both return clean output, you’re set.

that starter pack is deliberately conservative.

it gives you:

• a small loop

• a lean context shape

• a verification path

before you start getting fancy.

the best heartbeat.md files are boring on purpose.

a good heartbeat file should feel almost too small.

heartbeat works best as a checklist, not a strategy document.

why heartbeat gets expensive

heartbeats are full agent turns.

at a 30-minute cadence with full context, a single turn can run roughly 2,000–4,000 input tokens before the model writes a word.

across a 12-hour window, that’s 24–48 turns.

the math compounds fast.

these settings matter:

• isolatedsession: true → avoids full conversation history

• lightcontext: true → keeps bootstrap lean

• smaller heartbeat.md → fewer tokens per run

• cheaper model → lower per-turn cost

this is where people get it wrong.

they try to make heartbeat smarter before they make it smaller.

that’s how you end up paying tokens to maintain noise.

one honest limit:

heartbeat is not the lane for everything.

• exact timing → use cron

• deep work → use cron in isolation

• structured workflows → use lobster

heartbeat wins when the job is awareness, not ceremony.

how to verify it’s working

don’t trust heartbeat because it spoke.

trust it because you verified how it behaves.

critical rule

heartbeat_ok only works if placed at the start or end of the reply.

• openclaw strips it

• drops delivery if under ackmaxchars (default 300)

• ignores it if placed in the middle

this is where most people get tripped up.

visibility controls:

• showok

• showalerts

• useindicator

if all three are false:

heartbeat does not run at all.

silent ≠ running.

general health checks

openclaw status

openclaw gateway status

openclaw logs --follow

openclaw doctor

openclaw channels status --probe

heartbeat-specific checks

openclaw cron status

openclaw cron list

openclaw system heartbeat last

common skip reasons

• quiet-hours → outside active window

• requests-in-flight → system busy

• empty-heartbeat-file → nothing actionable

• alerts-disabled → suppressed output

heartbeat failures often look like silence.

that’s why guessing wastes time.

the interesting part of heartbeat is not that it exists.

the interesting part is that it forces you to decide:

• what deserves recurring attention

• what should stay manual

• what is worth paying tokens to notice

if you get it right:

• less noise

• less waste

• more trust

if you get it wrong:

• more messages

• more spend

• less belief in the system

the default rule is simple.

start with:

• one surface that changes

• one condition that matters

• one alert path you can review safely

then earn your way into anything bigger.

to start: drop in the config above, run the verification ladder, and watch one full cycle before you add anything.

if the cycle is clean and quiet, you’ve got a heartbeat worth building on.

the best heartbeat is usually boring.

it notices drift before drift becomes your job.

---

this is one piece.

sunday i’m dropping a full real-world build as a github repo inside the paid subscriber community here. full setup, prompts, configs, and assets for a system you can actually run.

if you’re tired of figuring this out alone, that’s where it goes deeper.