Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: WhatsApp aggressive 30-minute heartbeat causes cascading reconnects every ~60 seconds [5 comments, 3 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#55030•Fetched 2026-04-08 01:33:28
View on GitHub
Comments
5
Participants
3
Timeline
7
Reactions
0
Author
clawonelokeclawoneloke
Participants
clawonelokeclawonelokeFliztoneFliztonemaximizeGPTmaximizeGPT
Timeline (top)
commented ×5cross-referenced ×1subscribed ×1

Root Cause

The gateway intentionally reconnects WhatsApp Web after 30 minutes of message inactivity:

{"subsystem":"gateway/channels/whatsapp/heartbeat"} "No messages received in 30m - restarting connection"
{"subsystem":"gateway/channels/whatsapp"} "Web connection closed (status 499). Retry 1/12 in 2.3s... (status=499)"

After the first reconnect succeeds, the idle timer immediately fires again within ~60 seconds, creating a cascading loop:

17:03:17 - 30m idle, reconnect succeeds
17:04:28 - 31m idle, reconnect succeeds
17:05:40 - 32m idle, reconnect succeeds
17:06:52 - 33m idle, reconnect succeeds
17:08:03 - 35m idle, reconnect succeeds
17:09:14 - 36m idle, reconnect succeeds
17:10:26 - 37m idle, reconnect succeeds

Key observation: The idle duration keeps incrementing (30 to 31 to 32 to 33...), which suggests the idle counter does NOT properly reset after each reconnect.

Code Example

{"subsystem":"gateway/channels/whatsapp/heartbeat"} "No messages received in 30m - restarting connection"
{"subsystem":"gateway/channels/whatsapp"} "Web connection closed (status 499). Retry 1/12 in 2.3s... (status=499)"

---

17:03:17 - 30m idle, reconnect succeeds
17:04:28 - 31m idle, reconnect succeeds
17:05:40 - 32m idle, reconnect succeeds
17:06:52 - 33m idle, reconnect succeeds
17:08:03 - 35m idle, reconnect succeeds
17:09:14 - 36m idle, reconnect succeeds
17:10:26 - 37m idle, reconnect succeeds

---

Mar 26 17:03:17 [whatsapp] No messages received in 30m - restarting connection
Mar 26 17:03:17 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.3s... (status=499)
Mar 26 17:03:21 [whatsapp] Listening for personal WhatsApp inbound messages.
Mar 26 17:04:28 [whatsapp] No messages received in 31m - restarting connection
Mar 26 17:04:28 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.31s... (status=499)
Mar 26 17:04:33 [whatsapp] Listening for personal WhatsApp inbound messages.
Mar 26 17:05:40 [whatsapp] No messages received in 32m - restarting connection
Mar 26 17:05:40 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.2s... (status=499)
Mar 26 17:05:45 [whatsapp] Listening for personal WhatsApp inbound messages.
Mar 26 17:06:52 [whatsapp] No messages received in 33m - restarting connection
Mar 26 17:06:52 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.26s... (status=499)
Mar 26 17:06:56 [whatsapp] Listening for personal WhatsApp inbound messages.
RAW_BUFFERClick to expand / collapse

Bug Description

WhatsApp gateway exhibits cascading reconnects every ~60 seconds after the first 30-minute idle reconnect. This appears to be the aggressive 30-minute heartbeat reconnect documented in #13544 and #14000, still unresolved on v2026.3.24.

Root Cause

The gateway intentionally reconnects WhatsApp Web after 30 minutes of message inactivity:

{"subsystem":"gateway/channels/whatsapp/heartbeat"} "No messages received in 30m - restarting connection"
{"subsystem":"gateway/channels/whatsapp"} "Web connection closed (status 499). Retry 1/12 in 2.3s... (status=499)"

After the first reconnect succeeds, the idle timer immediately fires again within ~60 seconds, creating a cascading loop:

17:03:17 - 30m idle, reconnect succeeds
17:04:28 - 31m idle, reconnect succeeds
17:05:40 - 32m idle, reconnect succeeds
17:06:52 - 33m idle, reconnect succeeds
17:08:03 - 35m idle, reconnect succeeds
17:09:14 - 36m idle, reconnect succeeds
17:10:26 - 37m idle, reconnect succeeds

Key observation: The idle duration keeps incrementing (30 to 31 to 32 to 33...), which suggests the idle counter does NOT properly reset after each reconnect.

Environment

  • OpenClaw version: 2026.3.24 (very recent)
  • OS: Linux 6.6.87.2-microsoft-standard-WSL2 (x64)
  • Node: 22.22.1
  • Channel: WhatsApp

Steps to Reproduce

  1. Start OpenClaw gateway with WhatsApp channel connected
  2. Have the WhatsApp channel receive messages (active period)
  3. Leave channel idle for ~30 minutes with no inbound messages
  4. After first reconnect succeeds, observe cascading reconnects every ~60 seconds

Expected Behavior

  • After the 30-minute idle reconnect succeeds, the idle timer should reset and wait another 30 minutes before reconnecting again
  • OR the idle reconnect should not be triggered if the WebSocket is still healthy
  • OR the idle timeout interval should be configurable

Actual Behavior

  • First 30-minute reconnect works correctly
  • Subsequent reconnects fire every ~60 seconds in a cascading loop
  • Each reconnect generates system messages to WhatsApp chat
  • This generates significant noise in the chat

Gateway Logs

Full journalctl output:

Mar 26 17:03:17 [whatsapp] No messages received in 30m - restarting connection
Mar 26 17:03:17 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.3s... (status=499)
Mar 26 17:03:21 [whatsapp] Listening for personal WhatsApp inbound messages.
Mar 26 17:04:28 [whatsapp] No messages received in 31m - restarting connection
Mar 26 17:04:28 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.31s... (status=499)
Mar 26 17:04:33 [whatsapp] Listening for personal WhatsApp inbound messages.
Mar 26 17:05:40 [whatsapp] No messages received in 32m - restarting connection
Mar 26 17:05:40 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.2s... (status=499)
Mar 26 17:05:45 [whatsapp] Listening for personal WhatsApp inbound messages.
Mar 26 17:06:52 [whatsapp] No messages received in 33m - restarting connection
Mar 26 17:06:52 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.26s... (status=499)
Mar 26 17:06:56 [whatsapp] Listening for personal WhatsApp inbound messages.

Related Issues

  • #13544 - Aggressive 30-minute heartbeat reconnect (reported Feb 10, 2026)
  • #14000 - False scheduled reminder triggered on 499 reconnect (reported Feb 11, 2026)

The fix (reportedly in v2026.3.13) appears incomplete - the cascading reconnects after first reconnect are still occurring on v2026.3.24.

Suggested Fixes (Priority Order)

  1. Fix idle counter reset: Idle timer must reset its counter after each successful reconnect
  2. Use exponential backoff: After a reconnect, increase the idle timeout before next check (e.g., 30m to 35m to 40m to 60m max)
  3. Health-check before reconnect: Only reconnect if WebSocket is genuinely unhealthy, not just based on message inactivity
  4. Configurable interval: Make the 30-minute interval configurable
  5. Suppress noise during graceful shutdown: When gateway is restarting, do not send WhatsApp disconnect system messages to the WhatsApp channel

extent analysis

Fix Plan

To address the cascading reconnects issue, we will implement the following steps:

  1. Fix idle counter reset: Reset the idle timer counter after each successful reconnect.
  2. Use exponential backoff: Increase the idle timeout before the next check after a reconnect.

Example Code Changes:

// Reset idle timer counter after successful reconnect
function onReconnectSuccess() {
  idleTimerCounter = 0; // Reset counter
  idleTimeout = 30 * 60 * 1000; // Reset timeout to 30 minutes
}

// Use exponential backoff for idle timeout
function onReconnectFailure() {
  idleTimeout = Math.min(idleTimeout * 1.2, 60 * 60 * 1000); // Increase timeout by 20% up to 1 hour
}

// Update the reconnect logic to use the new idle timeout
function checkIdleTimeout() {
  if (idleTimerCounter >= idleTimeout) {
    // Reconnect logic here
  }
}

Configuration Changes:

  • Consider adding a configuration option to make the idle timeout interval configurable.

Verification

To verify the fix, follow these steps:

  1. Start the OpenClaw gateway with the WhatsApp channel connected.
  2. Leave the channel idle for ~30 minutes with no inbound messages.
  3. Observe the reconnect behavior after the first reconnect succeeds.
  4. Verify that the idle timer counter resets after each successful reconnect.
  5. Verify that the reconnects do not occur in a cascading loop.

Extra Tips

  • Monitor the gateway logs to ensure that the reconnect behavior is as expected.
  • Consider implementing additional logging to track the idle timer counter and reconnect attempts.
  • Review the related issues (#13544 and #14000) to ensure that the fix addresses all known problems.

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…
#model download#tokenizer error#prompt formatting#chain error#conversation history

Still need to ship something?

×6

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

Back to top recommendations

TRENDING