The OpenClaw Heartbeat: Your AI That Acts Without Being Asked

There's a Hacker News post from this weekend that's been stuck in my head. The title: "What if the browser built the UI for you?" — a thought experiment about flipping the relationship between tool and user. Instead of the user asking for things, the system anticipates and acts. It got 600+ points because it touches something real.

Every AI product built in the last three years has the same fundamental architecture: you type, it responds. The model is reactive by design — it has no agency until you invoke it. This works fine for a chatbot. It's a hard ceiling for anything you'd actually call an agent.

OpenClaw has a system that most users never fully configure: the heartbeat. It's the mechanism that lets your agent wake up unprompted, execute work, and check back in without you lifting a finger. Combined with cron scheduling and the wake event system, it's the closest thing to a genuinely autonomous local agent that exists right now. Most people have it set to disabled and have no idea what they're missing.

Most AI assistant setups follow the same pattern: you open Telegram, type something, get a reply, close the app. This is fine for answering questions. It's useless for the class of tasks that matter most — the ones with time sensitivity, the ones where you need to be told something rather than asking for it.

Your portfolio dropped 8% overnight. A competitor just published a press release. Your server's disk hit 90% at 3am. Your assistant knows exactly where to look for all of this — but it won't go look unless you ask. That gap between "tool that answers questions" and "system that watches the world for you" is where most AI setups fail.

The standard workaround is cron jobs — scheduling tasks to run at fixed intervals. And cron jobs are genuinely useful. But they're not the same as heartbeat. Cron fires on a schedule regardless of context. Heartbeat is smarter: it's the persistent pulse that keeps your agent's session alive and responsive to both scheduled events and dynamic triggers. Understanding the difference is what separates a well-configured OpenClaw from one that's just an expensive cron daemon.

OpenClaw's heartbeat is an interval-based session keepalive that also functions as a trigger surface. At its simplest: the gateway pings the agent session on a regular interval. The agent wakes up, checks whether there's anything to do, and either acts or goes back to sleep. No message from you required.

The key architectural detail is that heartbeat events are injected into the session as system events — the same mechanism as wake events and cron payloads. This means your agent's full tooling is available during a heartbeat: web search, file system, browser control, messaging. It's not a lightweight ping. It's a full agent turn, just initiated by the system instead of by you.

There are two modes worth understanding. Passive heartbeat keeps the session warm and ready — useful for reducing cold-start latency on reactive setups.Active heartbeat injects a system event text at each interval, giving the agent something to actually act on. The active mode is where things get interesting.

heartbeat:
  enabled: true
  intervalMs: 300000         # 5-minute pulse
  mode: active               # fires system events
  text: |
    Heartbeat check. Review any pending cron jobs,
    check for urgent items in MEMORY.md, and confirm
    the last scheduled task completed successfully.
    Act on anything time-sensitive; otherwise sleep.
  idleThresholdMs: 600000    # 10min idle before full wake

The text field is the instruction the agent receives at each heartbeat. This is where you encode standing orders — the things the agent should always check when it wakes up. Think of it as a recurring agenda that runs in the background whether or not you're paying attention.

If heartbeat is the persistent pulse, wake events are the interrupt signal. A wake event fires immediately — no waiting for the next interval — and injects an arbitrary message into the session. The practical use case: you want to trigger agent behavior based on an external event without having to manually open Telegram and type something.

OpenClaw exposes wake events through the cron API. You can fire them from shell scripts, webhooks, or other cron jobs. A monitoring script that detects a spike in your server error rate can fire a wake event that tells your agent to investigate and alert you. A price alert threshold getting crossed can wake the agent to pull market data and send a summary. The agent becomes reactive to the world, not just to your messages.

# From any script that detects something important
openclaw cron wake \
  --text "ALERT: Production error rate exceeded 5% threshold.
          Check logs at /var/log/app/error.log, identify root cause,
          and send a summary to Telegram immediately." \
  --mode now

# Or via the cron API (for webhook integrations)
curl -X POST http://localhost:3000/api/cron/wake \
  -H "Authorization: Bearer ${OPENCLAW_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"text": "Price alert: ETH dropped 7% in the last hour. Pull current data and summarize.", "mode": "now"}'

The --mode now flag bypasses the heartbeat interval entirely. The agent wakes within milliseconds. Compare that to next-heartbeat, which queues the event for the next scheduled pulse. For time-sensitive triggers, always use now.

The right heartbeat interval is not 1 minute. I've seen setups with 60-second pulses, and they're burning API tokens for no reason — the agent wakes up 1,440 times a day and most of the time has nothing to do. Unless you're building a real-time monitoring system that genuinely needs sub-minute response, start at 5 or 10 minutes and tune from there.

The heartbeat text is the most important thing to get right. It should be an instruction that's always valid — something the agent can do something with at 3am on a Tuesday or during a busy Thursday afternoon. Don't make it task-specific; make it a standing operating procedure.

heartbeat:
  enabled: true
  intervalMs: 600000   # 10 minutes

  # Passive mode: just keep session warm, fire no events
  # mode: passive

  # Active mode: inject this text at each pulse
  mode: active
  text: |
    Routine heartbeat. Do the following:
    1. Check MEMORY.md for any flagged TODOs marked [URGENT]
    2. Verify the last cron job completed without errors
    3. If nothing is urgent, do nothing and return silently
    4. If something needs attention, act and then notify via Telegram

  # Don't wake if user was active in the last 5 minutes
  idleThresholdMs: 300000

Notice the idleThresholdMs parameter. This suppresses heartbeat events when the session was recently active — meaning if you're actively chatting with your agent, it won't interrupt with background tasks. The heartbeat fires only when the session has been idle long enough to make it worth waking. This is one of the subtler config options that dramatically improves the feel of the system.

These are patterns that make the heartbeat actually earn its keep. They're not toy examples — they're things worth running.

heartbeat:
  mode: active
  text: |
    Check /var/log/app.log for ERROR lines in the last 10 minutes.
    If error count > 5: alert via Telegram immediately.
    If error count 1-5: log to MEMORY.md under [ERRORS].
    If clean: do nothing, return silently.
  intervalMs: 600000

heartbeat:
  mode: active
  intervalMs: 3600000  # hourly
  text: |
    Review MEMORY.md. Mark completed TODOs as [DONE].
    Remove entries older than 7 days that aren't marked [KEEP].
    Flag any deadline within 48h as [URGENT].
    Save updated MEMORY.md.

# Triggered via wake event from a health check script
#!/bin/bash
DISK=$(df -h / | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$DISK" -gt 85 ]; then
  openclaw cron wake \
    --text "Disk usage at ${DISK}%. Check /var/log for large files and alert." \
    --mode now
fi

The broader conversation in the builder community right now is circling around exactly this tension. On Hacker News this weekend, a post titled "What if the browser built the UI for you?" generated 600+ points and 140 comments — most of them not about browsers at all, but about the broader question of whether AI systems should be reactive tools or proactive participants. The top comment threads kept returning to the same frustration: every AI product announces itself as an "agent" but architecturally behaves like an autocomplete with an API key. The developer consensus seems to be that what actually constitutes agency is a system that can decide to act without a human prompt in its inbox. OpenClaw's heartbeat is one of the few production implementations of this that's actually running on real hardware in real workflows — and the r/LocalLLaMA discussions (when the Reddit API cooperates) consistently cite persistent, scheduled agent turns as the feature that separates toy setups from daily-driver infrastructure. X threads on agent automation in 2026 echo the same theme: the value of an AI agent compounds not from any single interaction but from the accumulated weight of hundreds of small, unprompted actions taken while you were doing something else.

The most common mistake: writing a heartbeat instruction that's too aggressive. If you tell the agent to "check email, search for news, and send a morning brief" at every 5-minute heartbeat, you're going to run 288 morning briefs per day and a token bill that looks like a ransomware attack. Heartbeat instructions should be conditional — the agent should do something only when there's actually something to do.

The second mistake is not setting idleThresholdMs. Without it, the heartbeat fires mid-conversation and interrupts whatever you were asking the agent to do. It's jarring and often breaks multi-step tasks. Set it to at least 5 minutes — 10 is safer.

Third: don't use heartbeat as a replacement for properly designed cron jobs. Heartbeat is for ambient awareness and quick checks. Heavy tasks — research, long web fetches, complex multi-tool workflows — belong in dedicated cron jobs with proper scheduling. Mixing the two makes debugging significantly harder.

Finally: test your heartbeat text in isolation before enabling it. Send it to the agent as a manual message and watch what happens. If the agent takes 45 seconds and makes 12 tool calls, you don't want that firing every 10 minutes while you sleep. Tune for fast, conditional execution.

The absolute minimal setup to try this: enable passive heartbeat, watch that your session stays warm across long idle periods, and observe the latency difference when you next send a message. That alone is worth the config change. Then graduate to active mode with a simple MEMORY.md review instruction. Run it for 48 hours and audit the results.

# Step 1: Edit your config
openclaw config.get

# Step 2: Patch in heartbeat settings
# Add to your ~/.openclaw/config.yaml:

heartbeat:
  enabled: true
  intervalMs: 900000        # 15 minutes — conservative start
  mode: active
  idleThresholdMs: 600000   # 10 min idle before firing
  text: |
    Routine heartbeat. Only act if:
    - MEMORY.md has any [URGENT] items
    - Last cron job failed (check run history)
    Otherwise return silently. Do not send messages.

# Step 3: Restart the gateway
openclaw gateway restart

# Step 4: Verify heartbeat is firing
# Watch your agent session — first active fire should occur
# within 15 minutes of idle time

From there, the path is clear: add a wake event trigger to one of your existing monitoring scripts, build a Context Gardener heartbeat for MEMORY.md, and start chaining the heartbeat with your existing automation workflows. The reactive trap is easy to escape once you have the mental model. You don't build a better chatbot — you build a system that watches, decides, and acts. The heartbeat is what makes that possible.