Bug type

Behavior bug (incorrect output/state without crash)

Summary

OpenClaw Version: 2026.3.13 (61d171a) OS: Ubuntu 24.04 (Hetzner VPS) Node.js: 22.22.1 Gateway Mode: local, loopback bind

Description:

The gateway/heartbeat subsystem initializes correctly on gateway startup (heartbeat: started with intervalMs: 600000) but never fires any heartbeat cycles. No agent sessions are created, no heartbeat check-ins occur. The agent configured with a heartbeat schedule simply never runs.

Steps to reproduce

1. Configure a gateway agent with a heartbeat schedule in openclaw.json:

{
  "agents": {
    "list": [
      { "id": "main" },
      {
        "id": "mc-gateway-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "name": "My Gateway Agent",
        "workspace": "/root/.openclaw/workspace/workspace-gateway-xxx/",
        "agentDir": "/root/.openclaw/agents/mc-gateway-xxx/agent",
        "heartbeat": {
          "every": "10m",
          "includeReasoning": false,
          "target": "last"
        }
      }
    ]
  }
}

1. Start the gateway: systemctl --user start openclaw-gateway
2. Observe logs: journalctl --user -u openclaw-gateway -f
3. Wait 15+ minutes

Key Evidence:

• Before restart: Heartbeats WERE firing. The gateway process (PID 1756278, running since Mar 20) showed heartbeat-triggered agent activity every 10 minutes (exec tool calls at :01, :11, :21, :31, etc.). This confirms the heartbeat config IS valid and the agent CAN run.

• After restart: Gateway process restarted (new PID). The heartbeat subsystem logs heartbeat: started but never fires. Restarted 4 times across 15 minutes — same behavior every time. Only heartbeat: started, never any execution.

• Cron subsystem works fine in the same process — cron: timer armed fires every minute as expected. This rules out general timer/scheduler issues in the Node.js process.

• Config is intact — The agents.list entry with heartbeat.every: "10m" is present and valid (verified via python3 -c "import json; ..."). The config didn't change between the working state (before restart) and the broken state (after restart).

Expected behavior

Heartbeat agent session fires every 10 minutes (per `heartbeat.every: "10m"

Actual behavior

Only the initialization log appears. No heartbeat sessions are ever created:

2026-03-23T10:21:29+00:00 [gateway/heartbeat] heartbeat: started {"intervalMs": 600000}

No further heartbeat-related log entries appear — ever. The cron subsystem (same gateway process) works correctly during this time:

2026-03-23T10:22:29+00:00 cron: timer armed
2026-03-23T10:23:29+00:00 cron: timer armed
2026-03-23T10:24:29+00:00 cron: timer armed
...

OpenClaw version

2026.3.13 (61d171a)

Operating system

Ubuntu 24.04

Install method

npm global

Model

openrouter/qwen/qwen3.5-122b-a10b

Provider / routing chain

openclaw -> openrouter -> qwen

Additional provider/model setup details

No response

Logs, screenshots, and evidence

**Log excerpt (full gateway log after restart):**


10:21:29 [INFO] [gateway/heartbeat] heartbeat: started {"intervalMs": 600000}
10:21:29 [INFO] [gateway/health-monitor] started (interval: 300s)
10:21:29 [INFO] [gateway] listening on ws://127.0.0.1:18789
10:21:29 [INFO] [telegram] starting provider
10:21:29 [DEBUG] cron: timer armed
10:22:29 [DEBUG] cron: timer armed
10:23:29 [DEBUG] cron: timer armed
10:24:29 [DEBUG] cron: timer armed
10:25:29 [DEBUG] cron: timer armed
... (continues with only cron entries, no heartbeat)

Impact and severity

No response

Additional information

Workaround:

We created a systemd timer that sends heartbeats externally via curl, reading the agent's auth token from TOOLS.md:

# Runs every 5 minutes, auto-discovers all gateway agents
curl -s -X POST "${BASE_URL}/api/v1/agent/heartbeat" \
  -H "X-Agent-Token: ${TOKEN_FROM_TOOLS_MD}"

This works but bypasses the agent's own liveness check (the agent could be hung but still appear online).

Additional Context:

This gateway also has Telegram channel configured (channels.telegram.enabled: true). The heartbeat.target is set to "last" — it's possible the scheduler skips firing because there's no "last" channel/session for the gateway agent after a fresh restart. If that's the case, a fallback behavior (fire anyway, skip delivery) would fix it.