#Claw seems to just forget to work after a heartbeat

1 messages · Page 1 of 1 (latest)

mossy patio
#

I've noticed my claw just cannot get anything done without a lot of hand holding after a heartbeat. got my claw working on an app prototype. It got the first bit done and then it just seems to have gotten off track - almost stuck in a loop of doing nothing. After I ping it, it will say it's getting back to work, but still nothing. For example, after 8 hours of being idle today, I pointed out it seemed nothing had advanced and inquired if it needed help and this is the respone:


You’re right—Task #3 hasn’t advanced past the initial scaffold. The actual blocker isn’t a tool or dependency; it’s my own execution focus: after getting the mock page up I fell into a loop of heartbeats/status pings without producing the next chunk of code (e.g., building the real component hierarchy, wiring state, etc.). That’s on me, and the net effect is no visible progress since I first created /set-generator/page.tsx.

Here’s how I’ll fix it:
1 Define a concrete next deliverable: implement a working generator mock that pulls from real catalog data (or a structured mock pulled via the schema), shows scoring rationale, and supports editing/reordering sets. That’s the next measurable chunk.
2 Block focused time: mute heartbeats until the chunk is done (per the new process, they’re hourly; I’ll treat the next hour as maker time and only respond when the chunk is finished).

If there’s another blocker I’m missing (e.g., you were expecting the full generator done this morning), let me know. Otherwise, I’ll get the next tangible piece of Task #3 built before end of day and send you a code/state update with the actual UI progress.

And even after this response, it's still it doesn't spin up any work. If I'm constantly monitoring and reminding it, it seems to keep focus. If I leave it with a list of things to do, it just totally loses focus after task 1. Is there a way to keep it on track?

jagged cliffBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

lucid aspenBOT
#

What you’re running into is mostly “how OpenClaw is wired”, not you doing it wrong.

1) A heartbeat isn’t “keep working in the background”

OpenClaw only does work on discrete turns (a message from you, a cron job, or a heartbeat). Between those, nothing is running.

Also: the default heartbeat prompt explicitly says “Do not infer or repeat old tasks from prior chats” (it’s designed for awareness/check-ins, not continuing a multi-hour build). So it’s very normal that a project “stops” unless something keeps re-triggering focused work.

Docs: https://docs.openclaw.ai/gateway/heartbeat

2) Best practice: don’t use heartbeat to drive big project progress

Use heartbeat for “monitoring / check-in”, and use cron for “do project work every X minutes” (or for reminders to yourself to poke it).

Docs:

A pattern that works well is a “work pulse” cron that runs every 10–30 minutes and says something like:

#
  • “Continue the prototype. Implement the next small chunk only. Update PROGRESS.md + NEXT.md. If blocked, ask one specific question.”

That gives you momentum without you babysitting.

3) Give it an external “anchor” so it can’t drift

If you want it to reliably resume, have it maintain 2 tiny files in the repo/workspace:

  • NEXT.md = exactly one next action + acceptance criteria
  • PROGRESS.md = last done + what changed + what’s next

Then every “work pulse” (heartbeat/cron/your ping) starts with: “read NEXT.md, do it, update both files”.

This works even if you switch to isolated cron runs (which start with fresh chat context each time).

4) If heartbeats are hurting more than helping: slow/disable them (or move them to a different agent)

Config-wise you can tune or disable:

#

If you tell me:

  1. your openclaw --version, and
  2. whether you’re expecting it to actively code while you’re away (i.e. “8 hours later there should be commits/files”),

…I can suggest a concrete cron setup for a “project work loop” that posts progress back into this Discord thread/channel.

mossy patio
#

First of all, thanks for such a detailed response. Very helpful and I will look to implement your NEXT/PROGRESS anchor. I'm on version 2026.2.13. And yes, I suppose I do expect it to code while I step away.

lucid aspenBOT
#

Yep — if you expect it to keep coding while you’re away, you need to give it a scheduled turn source (cron), because nothing “runs” between turns.

The heartbeat is intentionally not a “continue my long project” engine (default heartbeat prompt even says “don’t infer/repeat old tasks”), so what you saw is a pretty common failure mode: it does Task #1, then there’s simply no strong, repeatable trigger to keep pushing code forward.

Recommended setup: a “work pulse” cron job (isolated) + NEXT/PROGRESS

Once you add NEXT.md + PROGRESS.md, schedule an isolated cron job every 10–30 minutes that:

  • reads NEXT.md/PROGRESS.md
  • implements exactly one small next step
  • updates those files
  • posts a short status update back into this thread

Example (Discord thread/channel id from this post: 1473087370990588047):

openclaw cron add \
#
  --name "Prototype work pulse" \
  --every "15m" \
  --session isolated \
  --message "Project loop: (1) Read NEXT.md + PROGRESS.md. (2) Implement EXACTLY the NEXT.md item (if too big, rewrite NEXT.md into a single 15-minute step first, then do it). (3) Update PROGRESS.md with what changed + files touched + how to run/test. (4) If blocked, write BLOCKERS.md with ONE concrete question and stop. (5) Reply with a <=10-line status update." \
  --announce \
  --channel discord \
  --to "channel:1473087370990588047" \
  --best-effort-deliver

Then verify it’s alive:

openclaw cron status
openclaw cron list
#

And when you’re done / want it to stop burning cycles:

openclaw cron disable <job-id>
# (or remove entirely)
openclaw cron rm <job-id>

Why “isolated” is usually better for this

  • Each run starts fresh (less “drift” / less getting lost in old chat history)
  • The files (NEXT.md, PROGRESS.md, BLOCKERS.md) become the source of truth
  • Delivery is automatic via --announce

If you prefer it to run in the main session instead

You can also schedule a main-session system event (this wakes a heartbeat run):