Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Heartbeat polling silently stops after SIGUSR1 gateway restart [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78187•Fetched 2026-05-06 06:16:10
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
2
Author
SuidgeSuidge
Participants
clawsweeper[bot]clawsweeper[bot]SuidgeSuidge
Timeline (top)
commented ×1

Error Message

  • No error logs or warnings about the heartbeat scheduler being stuck

Code Example

2026-05-06T00:17:00.728+08:00 [gateway] received SIGUSR1; restarting
2026-05-06T00:17:01.345+08:00 [gateway] restart mode: full process restart (supervisor restart)
2026-05-06T00:17:08.569+08:00 [heartbeat] started    ← last heartbeat entry
# (no heartbeat entries for the next ~9.5 hours)

---

Heartbeat: 30m (silvermoon), disabled (agent-codex), disabled (silvermoon-b)
RAW_BUFFERClick to expand / collapse

Bug Description

Heartbeat polling silently stops after a SIGUSR1 gateway restart. The heartbeat mechanism (configured with every: "30m") does not resume firing after the restart, even though the gateway process itself is running normally and cron jobs continue to execute on schedule.

Reproduction

  1. Gateway receives SIGUSR1 restart (via openclaw gateway restart or programmatic SIGUSR1)
  2. Heartbeat fires once immediately after restart
  3. Heartbeat never fires again until the next full gateway process restart

Evidence

Gateway log (logs/gateway.log):

2026-05-06T00:17:00.728+08:00 [gateway] received SIGUSR1; restarting
2026-05-06T00:17:01.345+08:00 [gateway] restart mode: full process restart (supervisor restart)
2026-05-06T00:17:08.569+08:00 [heartbeat] started    ← last heartbeat entry
# (no heartbeat entries for the next ~9.5 hours)

Cron jobs continued running normally during the gap (proves gateway was alive):

JobLast RunStatus
Daily Memory Distillation (04:00)05-06 04:00ok
Morning Git EOD Cleanup (06:00)05-06 06:00ok
Morning Briefing (07:00)05-06 07:00ok
OpenRouter Monitor (08:00)05-06 08:00ok

openclaw status output during the gap showed:

Heartbeat: 30m (silvermoon), disabled (agent-codex), disabled (silvermoon-b)

— indicating heartbeat was configured but not actually firing.

Impact

  • All heartbeat-driven checks (email, GitHub notifications, todo reminders) were silently skipped for ~9.5 hours
  • No error logs or warnings about the heartbeat scheduler being stuck
  • User missed a todo reminder scheduled for 07:30

Environment

  • OpenClaw: 2026.5.4 (325df3e)
  • OS: macOS 26.4.1 (arm64)
  • Node: v25.9.0
  • Gateway: local LaunchAgent (active, pid 28130)
  • Heartbeat config: every: "30m", target: "feishu", directPolicy: "allow"

Expected Behavior

Heartbeat should resume its regular 30-minute polling cycle after a SIGUSR1 restart.

Notes

  • This is the second SIGUSR1 restart that day — multiple config changes were applied via gateway tool between 18:00–20:45 on May 5. Each restart was followed by at least one heartbeat firing, but the 00:17 restart on May 6 was the last one before the gap.
  • The gateway process itself was healthy (cron jobs, channels, sessions all functional).
  • Heartbeat resumed only after I manually triggered another restart via the gateway tool.

extent analysis

TL;DR

The heartbeat polling mechanism may need to be manually restarted or reconfigured after a SIGUSR1 gateway restart to resume its regular polling cycle.

Guidance

  • Verify that the heartbeat configuration is correct and not overridden after the SIGUSR1 restart by checking the openclaw status output and the heartbeat configuration file.
  • Check the gateway logs for any errors or warnings related to the heartbeat mechanism after the restart.
  • Consider adding a manual restart of the heartbeat mechanism after a SIGUSR1 restart as a temporary workaround.
  • Investigate if there are any issues with the every: "30m" configuration or the target: "feishu" setting that could be causing the heartbeat to stop firing.

Example

No code snippet is provided as the issue seems to be related to the configuration and restart of the heartbeat mechanism rather than a code-specific problem.

Notes

The issue may be related to the specific version of OpenClaw (2026.5.4) or the Node version (v25.9.0) being used. Further investigation is needed to determine the root cause of the problem.

Recommendation

Apply a workaround by manually restarting the heartbeat mechanism after a SIGUSR1 restart, as this has been shown to resume the heartbeat polling cycle in the past. This workaround can be used until a more permanent fix is found.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#SSR setup#ISR setup#authentication setup#request error#file not found

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Heartbeat polling silently stops after SIGUSR1 gateway restart [1 comments, 2 participants]