Summary

On WSL2, enabling both Telegram and WhatsApp channels caused the OpenClaw gateway to become unstable: channel startup/recovery repeatedly timed out, the Node event loop became heavily delayed, memory crossed the warning threshold, and supervisor restart handoffs eventually put the gateway into a restart loop.

Disabling both telegram and whatsapp at the channel and plugin layers stabilized the gateway immediately.

Environment

• OpenClaw Gateway: v2026.6.8
• Host: WSL2 Ubuntu 24.04 on Windows
• Service: systemd --user unit openclaw-gateway.service
• Gateway command: /usr/bin/node .../openclaw/dist/index.js gateway --port 18789

Symptoms observed

The gateway would start and reach HTTP readiness, but then channel health/recovery work would cause long stalls and eventual restarts.

Representative log lines, with secrets redacted:

[gateway] http server listening (16 plugins: ..., telegram, ..., whatsapp, ...)
[telegram] [default] starting provider
[telegram] fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=request-timeout)
[telegram] deleteMyCommands failed: Network request for 'deleteMyCommands' failed!
[telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
[telegram] setMyCommands failed: Network request for 'setMyCommands' failed!
[whatsapp] auth state is still stabilizing. Retry 1/12 for inbox attach ...
[whatsapp] Web connection closed during setup (status 428). Retry ...
[whatsapp] Web connection closed (status 408). Retry ...
[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu ... eventLoopDelayP99Ms=17700 eventLoopDelayMaxMs=17700 eventLoopUtilization=1 ...
[diagnostics/memory] memory pressure: level=warning reason=rss_threshold rss=1.54 GiB threshold=1.5 GiB
[health-monitor] [telegram:default] health-monitor: restarting (reason: disconnected)
[health-monitor] [whatsapp:default] health-monitor: restarting (reason: disconnected)
[shutdown] completed cleanly in 13190ms
[gateway] restart mode: full process restart (supervisor restart)

A supervisor handoff was also present:

{
  "kind": "gateway-supervisor-restart-handoff",
  "reason": "cron.isolated_agent_setup_timeout",
  "restartKind": "full-process",
  "supervisorMode": "systemd"
}

The stability reports directory contained repeated files like:

openclaw-stability-...-gateway.restart_shutdown_timeout.json
openclaw-stability-...-gateway.stop_shutdown_timeout.json

Workaround that stabilized the service

I changed the config to disable Telegram and WhatsApp both as channels and plugin entries:

{
  "channels": {
    "telegram": { "enabled": false },
    "whatsapp": { "enabled": false }
  },
  "plugins": {
    "entries": {
      "telegram": { "enabled": false },
      "whatsapp": { "enabled": false }
    }
  }
}

After forcing the wedged gateway process down, removing the stale gateway-supervisor-restart-handoff.json, and restarting the service, the gateway stayed active:

ActiveState=active
SubState=running
NRestarts=0
HTTP/1.1 200 OK
[gateway] http server listening (14 plugins: acpx, active-memory, browser, device-pair, diffs, google, lobster, lossless-claw, memory-core, memory-wiki, openrouter, searxng, webhooks, workboard)

Expected behavior

A channel with unreachable external API or unstable auth state should degrade independently without starving the gateway event loop or causing supervisor-level restart loops. Ideally:

• Telegram command sync / webhook cleanup / polling setup should use bounded retries and backoff.
• WhatsApp reconnect/auth stabilization should not keep the gateway in a high-pressure recovery path.
• Channel health monitor restarts should be circuit-broken after repeated failures.
• Gateway shutdown/restart should not block on slow channel teardown beyond a strict deadline.

Notes

The Telegram config in this case included many groups/topics and thread bindings, so command sync/setup may have been heavier than usual. Still, the gateway should remain responsive and avoid full restart loops when Telegram or WhatsApp is degraded.