openclaw - 💡(How to fix) Fix Windows startup feels slow because Telegram recovery is consistently slow and Feishu sometimes times out during startup [1 comments, 2 participants]

Environment

• OpenClaw version: 2026.4.15
• OS: Windows 10 x64
• Node: v22.22.2
• Channels enabled: Telegram, Feishu
• Feishu mode: websocket
• Network: Wi-Fi, no system proxy configured

Summary

On this machine, OpenClaw feels slow to become fully usable after startup, but the delay is not explained by core gateway boot alone.

What we observed is a split startup:

1. the gateway itself reaches ready in ~55s
2. channel recovery continues afterward
3. Telegram is consistently slow on this network
4. Feishu intermittently times out during startup token / bot identity recovery and falls back to background retry

So from the user’s point of view, startup is "slow every time", even though the visible delay is largely caused by channel recovery lagging behind core gateway readiness.

Observed startup timeline

01:31:10 [gateway] loading configuration…
01:31:13 [gateway] starting...
01:32:08 [gateway] ready (8 plugins: acpx, browser, device-pair, feishu, memory-core, phone-control, talk-voice, telegram; 55.1s)
01:32:10 [gateway] starting channels and sidecars...
01:32:21 [info]: [ 'client ready' ]

This means:

• core gateway startup is already somewhat slow (~55s)
• but the larger usability problem is that channels are still recovering after that

Feishu evidence

During startup recovery, Feishu hit both timeout and TLS/socket failure paths:

01:35:53 AxiosError: timeout of 30000ms exceeded
url: https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal

01:40:59 AxiosError: Client network socket disconnected before secure TLS connection was established
url: https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal
code: ECONNRESET

01:40:59 [feishu] feishu[default]: bot open_id unknown; starting background retry
01:41:59 [feishu] feishu[default]: bot open_id recovered via background retry

So Feishu startup can degrade into a timeout/retry path even with valid app credentials.

Telegram evidence

Telegram also shows startup recovery problems:

01:35:53 [telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_SOCKET)
01:41:49 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
01:41:49 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.44s.

Network checks on the same machine show Telegram is consistently much slower than Feishu:

• https://open.feishu.cn/... token requests: ~124–144ms when healthy
• https://api.telegram.org HEAD requests: ~1746–1785ms consistently
• ping api.telegram.org mostly times out on this network
• traceroute to Telegram becomes non-responsive much earlier than Feishu

This suggests Telegram is a persistent slow path on this network, while Feishu adds intermittent startup-time failures.

Why this matters

From the user’s perspective, OpenClaw startup success is not just "gateway ready".

If the main gateway becomes ready, but Telegram/Feishu remain degraded for another 1–6 minutes, the practical experience is still:

• startup feels slow
• channel recovery feels unreliable
• it is hard to tell whether OpenClaw is actually usable yet

Related issues

These seem directionally related:

• #68781 gateway startup extremely slow
• #63475 Feishu startup bot info probe timeout
• #40327 Telegram polling stall after gateway restart
• #54219 one channel failure blocks or degrades overall startup experience

Suggested improvements

1. Distinguish gateway ready from channels fully recovered in startup UX/logging
2. Add a per-channel startup timing summary after boot
3. Prevent one degraded channel from dominating the perceived startup success state
4. Make Feishu token/bot identity recovery more defensive (retry strategy / serialization / clearer degraded status)
5. Surface Telegram webhook cleanup / network fallback problems earlier and more clearly
6. Consider fault-isolating slow channel recovery from the main startup-ready signal

Key point

This report is not claiming only one root cause.

It looks like a combination of:

• non-trivial core gateway startup time (~55s)
• persistently slow Telegram network path on this machine
• intermittent Feishu startup timeout / ECONNRESET / background retry

Together, these make OpenClaw feel slow to start "every time" in real-world use.