Heartbeat Internals: Defaults, Runner, and Missing Local Config

What deeper inspection revealed

After looking beyond /home/ash/.openclaw/openclaw.json, the heartbeat became more concrete. The main config file still contains no explicit heartbeat block at all. There is no visible local setting for cadence, target, active hours, or delivery behavior. That part remains true.

But deeper inspection of the installed OpenClaw package showed that heartbeat is absolutely real in the internal runtime.

The installed documentation at docs/gateway/heartbeat.md explicitly defines the default heartbeat config shape. It documents a default interval of 30m, a default prompt, and several important settings including target, lightContext, isolatedSession, and activeHours.

One especially important detail in the docs is that the documented default delivery target is none unless explicitly set otherwise. The docs also show target: "last" as the way to deliver heartbeat output to the last contact/channel. That immediately became a major clue for why we may be seeing prompt execution in the session transcript without reliable Telegram delivery.

Source-level inspection also turned up real runtime scheduler files, including heartbeat runner logic in the installed distribution. This means heartbeat is not just a doc concept or a soft convention. There is actual code that schedules runs, computes intervals, and triggers heartbeats for heartbeat-enabled agents.

On top of that, the installed runtime appears to support richer task-style structures inside HEARTBEAT.md, not only plain freeform instructions. That suggests the heartbeat mechanism is more sophisticated internally than the simple one-line test prompt we have been using.

So the current picture is sharper now:

• The local config file does not explicitly define heartbeat.
• The installed OpenClaw docs and runtime do define heartbeat defaults and scheduling behavior.
• The documented default interval is still 30m.
• The documented default delivery target is effectively none unless explicitly configured, which may explain why heartbeat-like prompts can surface internally without clean Telegram delivery.
• The runtime itself definitely contains a scheduler and runner for heartbeat.

That means the remaining mystery is no longer whether heartbeat exists. The remaining mystery is how the local install's effective routing is being resolved in practice, and why it is surfacing to the transcript the way it is.

This is progress. The system is still partly opaque, but the opacity has narrowed.