Description
The built-in Discord health-monitor fires 'stuck' reconnects at an extremely high rate even when the gateway is otherwise healthy — cron jobs running, messages flowing, no WS death spiral in progress.
Environment
- OpenClaw: v2026.3.2
- OS: Windows 10 x64
- Discord channel, single guild
Observed behaviour
The health-monitor logs \health-monitor: restarting (reason: stuck)\ approximately every 10 minutes, sustained over multiple hours. Each forced reconnect takes ~9-10 seconds during which Discord is unavailable.
Example from our gateway logs (6 March 2026, a representative 1-hour window):
\
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
\\
This ran continuously for 4+ hours (30+ occurrences in a single day). Between each reconnect, the gateway was demonstrably functional: cron jobs completing successfully, messages being sent and received, memory search working.
Expected behaviour
The health-monitor should only trigger a reconnect when the Discord connection is genuinely unresponsive, not on a fixed ~10-minute cadence regardless of connection health.
Suspected cause
The health-monitor's 'stuck' detection threshold may be based on message receive frequency or heartbeat timing. During periods of low message activity (no user messages for 10+ minutes), the connection is classified as 'stuck' even though it is alive and the gateway is functioning normally.
This is distinct from the WS death spiral fixed in #13688 — those are actual 1005/1006 drops. This is the health-monitor proactively killing a healthy connection.
Impact
- ~9-10 seconds of Discord unavailability per occurrence
- 30+ unnecessary reconnects per day
- Significant log noise making real issues harder to spot
- Potential to trigger rate limits on heavy reconnect days
Workaround
None currently — the health-monitor interval/threshold is not configurable.
Description
The built-in Discord health-monitor fires 'stuck' reconnects at an extremely high rate even when the gateway is otherwise healthy — cron jobs running, messages flowing, no WS death spiral in progress.
Environment
Observed behaviour
The health-monitor logs \health-monitor: restarting (reason: stuck)\ approximately every 10 minutes, sustained over multiple hours. Each forced reconnect takes ~9-10 seconds during which Discord is unavailable.
Example from our gateway logs (6 March 2026, a representative 1-hour window):
\
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
[discord:default] health-monitor: restarting (reason: stuck) → reconnected in 9s
\\
This ran continuously for 4+ hours (30+ occurrences in a single day). Between each reconnect, the gateway was demonstrably functional: cron jobs completing successfully, messages being sent and received, memory search working.
Expected behaviour
The health-monitor should only trigger a reconnect when the Discord connection is genuinely unresponsive, not on a fixed ~10-minute cadence regardless of connection health.
Suspected cause
The health-monitor's 'stuck' detection threshold may be based on message receive frequency or heartbeat timing. During periods of low message activity (no user messages for 10+ minutes), the connection is classified as 'stuck' even though it is alive and the gateway is functioning normally.
This is distinct from the WS death spiral fixed in #13688 — those are actual 1005/1006 drops. This is the health-monitor proactively killing a healthy connection.
Impact
Workaround
None currently — the health-monitor interval/threshold is not configurable.