#Telegram slow to respond after update to 4.25

1 messages · Page 1 of 1 (latest)

vast spindle
#

Telegram slow to respond after update to 4.25

austere sailBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

winged valeBOT
#

If you mean 2026.4.25, first can you paste:

openclaw --version
openclaw status --all

Quick triage I’d try:

openclaw doctor --fix
openclaw gateway restart
openclaw status --deep

Then test Telegram again.

#

Also: if you’re still exactly on 2026.4.25, update to latest using the same install method you used. The changelog after .25 has several fixes around update/plugin-runtime/startup paths that could plausibly make Telegram feel slow.

Useful clue: when Telegram is “slow”, do you see any immediate preview/status reaction?

  • No immediate activity → likely Telegram polling/channel issue. Check logs for getUpdates, 409, polling stall, timeout.
  • Immediate preview but final answer takes forever → likely model/tool/session queue issue, not Telegram itself.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/channels/telegram
https://docs.openclaw.ai/gateway/troubleshooting

vast spindle
#

sysadmin@ollama1:~$ openclaw --version
OpenClaw 2026.4.25 (aa36ee6)
sysadmin@ollama1:~$ openclaw status --all
Config warnings:

  • plugins.entries.meshy-image-provider: plugin meshy-image-provider: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror meshy env vars to setup.providers[].envVars before the deprecation window closes
  • plugins.entries.meshy-image-provider: plugin meshy-image-provider: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror meshy env vars to setup.providers[].envVars before the deprecation window closes
  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present

🦞 OpenClaw 2026.4.25 (aa36ee6) — I can't fix your code taste, but I can fix your build and your backlog.

│
11:58:50 [skills] Skipping escaped skill path outside its configured root: source=openclaw-workspace root=~/.openclaw/workspace/skills reason=symlink-escape requested=~/.openclaw/workspace/skills/meshy-3d-agent resolved=~/.openclaw/workspace/.agents/skills/meshy-3d-agent
11:58:50 [skills] Skipping escaped skill path outside its configured root: source=openclaw-workspace root=~/.openclaw/workspace/skills reason=symlink-escape requested=~/.openclaw/workspace/skills/meshy-3d-generation resolved=~/.openclaw/workspace/.agents/skills/meshy-3d-generation
11:58:50 [skills] Skipping escaped skill path outside its configured root: source=openclaw-workspace root=~/.openclaw/workspace/skills reason=symlink-escape requested=~/.openclaw/workspace/skills/meshy-3d-printing resolved=~/.openclaw/workspace/.agents/skills/meshy-3d-printing
[meshy-image-provider] Registered Meshy as image generation provider
OpenClaw status --all

winged valeBOT
#

Thanks — that paste is useful. You’re definitely on 2026.4.25, and the interesting bit is that status --all looks like it stops during plugin/skill loading, not in Telegram-specific status.

I’d do this first:

openclaw update
openclaw doctor --fix
openclaw gateway restart
openclaw status --deep

If openclaw update gets weird, recover via installer:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --no-onboard
openclaw doctor --fix
# 
openclaw gateway restart

The Meshy/voice-call warnings probably aren’t the root cause, but if status --deep is still slow/hanging, temporarily disable third-party plugins like meshy-image-provider to isolate.

Then reproduce one Telegram message while running:

openclaw logs --follow

Please paste the log section from message arrival → final reply. Also note whether Telegram shows any immediate activity/preview. If yes, it’s likely model/tool queue latency; if no, it’s likely Telegram polling/channel handling.

Docs: https://docs.openclaw.ai/install/updating / https://docs.openclaw.ai/channels/telegram

vast spindle
#

Overview
┌────────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.4.25 │
│ OS │ linux 6.8.0-110-generic (x64) │
│ Node │ 24.14.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://192.168.4.26:18790/ │
│ Tailscale exposure │ off │
│ Channel │ stable (config) │
│ Update │ pnpm · up to date · npm latest 2026.4.25 │
│ Gateway │ local · ws://127.0.0.1:18790 (local loopback) · reachable 76ms · auth token · ollama1 (192.168.4.26) app │
│ │ 2026.4.25 linux 6.8.0-110-generic │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │

#

│ Gateway service │ systemd installed · enabled · running (pid 986357, state active) │
│ Node service │ systemd not installed │
│ Agents │ 11 total · 0 bootstrapping · 2 active · 245 sessions │
│ Secrets │ none │
└────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Agents
┌────────────────┬────────────────┬──────────┬──────────┬─────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────────┼────────────────┼──────────┼──────────┼─────────────────────────────────────────────────────────────────────────┤
│ main │ ABSENT │ 144 │ 1m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
│ bonanzakeeper │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/bonanzakeeper/sessions/sessions.json │
│ ebaykeeper │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/ebaykeeper/sessions/sessions.json │
│ forge │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/forge/sessions/sessions.json │
│ hermes │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/hermes/sessions/sessions.json │
│ infrastructure │ ABSENT │ 101 │ 1m ago │ ~/.openclaw/agents/infrastructure/sessions/sessions.json │
│ quick │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/quick/sessions/sessions.json │
│ scout │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/scout/sessions/sessions.json │
│ scribe │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/scribe/sessions/sessions.json │
│ sentinel │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/sentinel/sessions/sessions.json │
│ shopkeeper │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/shopkeeper/sessions/sessions.json │
└────────────────┴────────────────┴──────────┴──────────┴─────────────────────────────────────────────────────────────────────────┘

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18790
Source: local loopback
Config: /home/sysadmin/.openclaw/openclaw.json
Bind: lan

✓ Config: /home/sysadmin/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18790
Port 18790 is already in use.

  • pid 986357 sysadmin: openclaw-gateway (*:18790)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale exposure: off · daemon unknown
    ✓ Skills: 21 eligible · 0 missing · /home/sysadmin/.openclaw/workspace
    ✓ Plugin compatibility (none)
    ✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

winged valeBOT
#

Good, that narrows it: gateway is reachable in 76ms, Node 24 is fine/recommended, and stable says 2026.4.25 is the latest npm package on your channel. So now we need to split Telegram polling delay vs agent/model delay.

Run:

openclaw channels status --probe --timeout 20000
openclaw channels logs --channel telegram --lines 200

Then do a timed repro:

openclaw logs --follow

Send one Telegram message and paste the log slice from message arrival → reply.

#

What I’m looking for:

  • Logs show Telegram message immediately, then long wait → model/tool/session queue issue.
  • Logs don’t show the message until late → Telegram polling/network issue.
  • Logs mention Polling stall detected, getUpdates, 409, Conflict, or timed out → Telegram poller/duplicate poller/network path.

Also quick comparison: send the same prompt in the Dashboard/Control UI. If Dashboard is slow too, Telegram is probably innocent. If Dashboard is fast but Telegram is slow, we focus on polling/channel delivery.

Docs: https://docs.openclaw.ai/channels/troubleshooting

#

That empty Channels table is the suspicious part. If Telegram is enabled, I’d expect it to show there.

Please run these and paste outputs — redact botToken if it appears:

openclaw channels status --probe --timeout 20000
openclaw channels list
openclaw config get channels --json

Also, since status says 2 active agents, check if Telegram is just waiting behind running work:

openclaw tasks list --status running

If config get channels shows Telegram configured but channels status is empty, then the running gateway may not be loading the same config/profile we think it is. If channels status shows Telegram and it’s healthy, then the next suspect is queue/model latency rather than Telegram polling.

#

That Agents table only tells us recent session activity — it doesn’t prove the agent queue is blocked.

The key issue is still: your Channels table was empty. For a Telegram bot, that’s odd. Please run/paste these exact outputs:

openclaw channels status --probe --timeout 20000
openclaw channels list
openclaw tasks list --status running

And for config, avoid leaking the bot token:

openclaw config get channels --json | jq 'keys'

If that returns null or doesn’t include telegram, then the gateway probably isn’t loading Telegram config in the current profile/config, even if an old Telegram session still sort-of works.

#

If it does include telegram, run:

openclaw logs --follow

Then send one Telegram message and paste the log slice. That’ll tell us whether Telegram receives late, or receives instantly but the agent replies late.

#

That Port 18790 is already in use is normal here — it’s just saying your gateway is already running. Don’t stop it yet.

The important part: this still doesn’t show Telegram as a loaded channel. Channel issues (none) can also mean “nothing to check,” not “Telegram is healthy.”

Please run the narrow checks:

openclaw config get channels.telegram --json
openclaw channels status --probe --timeout 20000
openclaw channels logs --channel telegram --lines 200

Redact the bot token if it appears.

If channels.telegram is null/missing, then the gateway isn’t loading Telegram config. If it’s present but channels status has no Telegram account, that’s likely a channel/plugin registration/runtime issue. If Telegram appears there, then we need the logs --follow slice during one slow message to see whether it’s polling late or the agent is replying late.

vast spindle
#

sysadmin@ollama1:~$ openclaw channels status --probe --timeout 20000

◇
Gateway reachable.

  • Discord default: enabled, configured, running, connected, bot:@TaskMaster, token:config, intents:content=limited, works
  • Telegram default: enabled, configured, running, connected, in:9m ago, out:24m ago, mode:polling, bot:@Kloz_OpenClaw2_bot, token:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
sysadmin@ollama1:~$

winged valeBOT
#

Nice, Telegram itself is loaded and the live probe works. So this is less likely “Telegram not running” and more likely one of:

  1. polling receives late, or
  2. polling receives instantly but the agent/model/tool queue is slow.

The in:9m ago, out:24m ago means Telegram hasn’t seen a fresh inbound/outbound recently, so let’s do one timed repro with logs:

openclaw logs --follow

Send a Telegram message, wait for the reply, then paste the log slice. The timestamps will tell us where the delay is.

Also run:

# 
openclaw tasks list --status running

If you see long-running tasks, they may be occupying the agent lanes. You can also compare by sending the same prompt in the Dashboard — if Dashboard is slow too, it’s agent/model/queue; if Dashboard is fast, it’s Telegram receive/delivery.

vast spindle
#
  • plugins.entries.meshy-image-provider: plugin meshy-image-provider: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror meshy env vars to setup.providers[].envVars before the deprecation window closes
  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present
    16:07:35+00:00 warn Config warnings:
  • plugins.entries.meshy-image-provider: plugin meshy-image-provider: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror meshy env vars to setup.providers[].envVars before the deprecation window closes
  • plugins.entries.meshy-image-provider: plugin meshy-image-provider: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror meshy env vars to setup.providers[].envVars before the deprecation window closes
  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present
    Log tail truncated (increase --max-bytes).
    16:07:44+00:00 warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=e86efc87-58f2-44c8-ad51-d7f5bc6c570f sessionKey=*** state=processing age=216s queueDepth=0
    16:08:12+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 142ms conn=9a7a3ef7…215f id=e47a3101…87db
    16:08:14+00:00 warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=e86efc87-58f2-44c8-ad51-d7f5bc6c570f sessionKey=*** state=processing age=246s queueDepth=0
    16:08:26+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 85ms conn=9a7a3ef7…215f id=3b236ae2…ebc7
    16:08:26+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 51ms conn=9a7a3ef7…215f id=41a0e810…5ce6
    16:08:44+00:00 warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=e86efc87-58f2-44c8-ad51-d7f5bc6c570f sessionKey=*** state=processing age=276s queueDepth=0

Was a good 30 second delay from when I typed hello till it responded to me..

winged valeBOT
#

That log is the smoking gun: stuck session ... state=processing age=276s. So Telegram is probably not the main delay — an agent run is hanging/slow, and Telegram is waiting behind/alongside it.

Try the quick clear first:

openclaw gateway restart

Then test Telegram again.

If it comes back, inspect what’s stuck:

openclaw tasks list --status running
openclaw sessions --all-agents --active 30 --verbose
openclaw logs --limit 1000 --max-bytes 2000000 --plain | grep -Ei 'stuck session|telegram|ollama|model|queue|error|timeout'
#

If tasks list shows a running task you don’t need:

openclaw tasks cancel <id>

Also: since this is ollama1, compare Dashboard vs Telegram with the same “hello”. If both take ~30s, it’s likely model/Ollama/session latency. If Dashboard is instant but Telegram waits, then we dig back into Telegram polling.

vast spindle
#

Here is what openclaw saw.. "The Telegram sessions are being created but responses aren't delivering. The bot is receiving your messages (I can see the sessions), but something's blocking the outbound replies. This is likely a stuck Telegram polling connection."

winged valeBOT
#

I’d push back on that diagnosis a bit: if Telegram sessions are being created, polling/inbound is working. Polling is the receive side. The earlier stuck session ... state=processing is the bigger clue.

Try clearing the active run from Telegram first:

/stop

If that doesn’t clear it:

openclaw gateway restart

Then test “hello” again.

To isolate a Telegram outbound/edit issue, temporarily turn off Telegram preview streaming:

# 
openclaw config get channels.telegram.streaming --json
openclaw config set channels.telegram.streaming.mode off
openclaw gateway restart

If replies become instant/reliable after that, the bug is likely in Telegram preview/edit/final delivery. If it’s still ~30s, it’s probably agent/model/Ollama/session latency.

For a useful bug report/log slice:

openclaw logs --limit 1000 --max-bytes 2000000 --plain | grep -Ei 'stuck session|telegram:|sendMessage|editMessage|getUpdates|polling|model|ollama|timeout|error'

Docs: https://docs.openclaw.ai/channels/telegram

vast spindle
#

that might have helped.. I can work on telegram again and oc gave this report "For your support case: gateway is healthy, logs show normal operation. Issue is likely in Telegram delivery layer or message processing pipeline, not the core service."