#Telegram is super slow

1 messages · Page 1 of 1 (latest)

fervent python
#

Hey Krill - on the latest version, Telegram became super slow. It replies to one topic at a time, and takes a lot longer than normal

shut rapidsBOT
#

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

hidden lanceBOT
#

Hey Julian — first thing: can you paste openclaw --version? Version mismatch/regression details matter here.

The behavior you’re describing sounds like one of two queues:

  1. Agent concurrency got effectively capped to 1
    Telegram forum topics should be isolated as :topic:<threadId>, but all inbound runs still share the main agent concurrency lane. Check:

    openclaw config get agents.defaults.maxConcurrent

    Default should be 4. If it’s 1, different Telegram topics will feel one-at-a-time. You can set it back with:

    openclaw config set agents.defaults.maxConcurrent 4
openclaw gateway restart

  2. Telegram send/edit rate limiting
    Recent builds share the Telegram API throttler across polling + preview/message sends, so if streaming previews/tool progress are doing lots of edits, replies can feel slower. As a quick test, try reducing Telegram streaming/progress previews temporarily and see if latency improves.

fervent python
#

│ Version │ 2026.5.2 │
│ OS │ linux 6.8.0-101-generic (x64) │
│ Node │ 22.21.1

hidden lanceBOT
#

Thanks — 2026.5.2 is exactly the useful detail.

Given that version, I’d check this in order:

openclaw config get agents.defaults.maxConcurrent
openclaw config get messages.queue
openclaw config get channels.telegram.streaming

Expected/healthy-ish baseline:

agents: { defaults: { maxConcurrent: 4 } }
messages: { queue: { mode: "steer" } }
#

If agents.defaults.maxConcurrent is 1, that would explain “one Telegram topic at a time”. Telegram long polling uses per-chat/per-thread sequencing, but the runner’s overall concurrency is still capped by agents.defaults.maxConcurrent.

If concurrency is already 4+, my next suspect is Telegram streaming/progress previews being throttled. 2026.5.x shares the Telegram API throttler more consistently, which is safer for Bot API limits but can make busy topic replies feel slower if lots of preview edits/tool-progress edits are happening.

Quick isolation test:

openclaw config set channels.telegram.streaming.mode off
openclaw gateway restart

Then try two topics again. If that makes it fast, we’ve narrowed it to Telegram preview/edit throttling rather than agent execution.

Also worth checking logs while triggering two different topics:

# 
openclaw logs --follow

Look for either queued for ...ms lines or session keys that don’t include :topic:<id>. If different Telegram topics are not getting :topic: session keys, that’s a routing bug and should go to GitHub with the log snippet: https://github.com/openclaw/openclaw/issues

fervent python
#

19:54:25+00:00 warn plugins {"subsystem":"plugins"} [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: brave (/home/julian/.openclaw/npm/node_modules/@openclaw/brave-plugin/index.ts). Set plugins.allow to explicit trusted ids.
19:54:26+00:00 warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=430.2 eventLoopDelayMaxMs=10871.6 eventLoopUtilization=0.725 cpuCoreRatio=0.767 active=3 waiting=0 queued=3
19:54:28+00:00 info channels/telegram {"subsystem":"channels/telegram"} telegram sendMessage ok chat=-1003941914353 message=76
19:54:48+00:00 warn agent/embedded {"subsystem":"agent/embedded"} [context-overflow-diag] sessionKey=agent:main:telegram:group:-1003941914353:topic:1 provider=openai-codex/gpt-5.5 source=assistantError messages=137 sessionFile=/home/julian/.openclaw/agents/main/sessions/dae13789-9aaf-4bc6-bf1c-2f6a11d5826f-topic-1.jsonl diagId=ovf-mp06z79c-oGYm7g compactionAttempts=0 observedTokens=unknown error=Context overflow: estimated context size exceeds safe threshold during tool loop.
19:54:48+00:00 warn agent/embedded {"subsystem":"agent/embedded"} context overflow detected (attempt 1/3); attempting auto-compaction for openai-codex/gpt-5.5
19:55:12+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 193ms conn=64dfed07…4411 id=cb2f1f02…74ae
19:55:13+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli session reset: provider=claude-cli reason=system-prompt

hidden lanceBOT
#

Yep, this log points away from Telegram itself.

The big signals are:

  • event_loop_delay ... maxMs=10871.6 ... active=3 ... queued=3 → the gateway event loop was blocked for ~10.8s and work is backing up.
  • context-overflow-diag ... topic:1 ... messages=137 → that Telegram topic session is huge / overflowing.
  • attempting auto-compaction → replies will wait while OpenClaw compacts and retries that session.

So the “one topic at a time” feeling is likely: overloaded gateway + one long topic hitting context overflow/compaction, causing queued runs behind it.

Immediate fix for that Telegram topic:

/compact

Send that in the slow Telegram topic. If it’s still wedged or you don’t care about that topic’s old context:

# 
/new

Then retest. For longer-term stability, I’d also do:

openclaw config get agents.defaults.maxConcurrent
openclaw config get channels.telegram.streaming
openclaw status --all

If this is a small VPS, lowering concurrency may actually help event-loop starvation even though it sounds backwards — active=3 with high event loop delay means the process is struggling, not just waiting on Telegram.

The plugins.allow is empty warning is probably not the direct cause, but you should still lock that down later since it’s loading a non-bundled Brave plugin. The smoking gun here is context overflow + event loop delay.

fervent python
#

19:56:24+00:00 warn gateway/reload {"subsystem":"gateway/reload"} config change requires channel reload (telegram) — deferring until 4 operation(s), 2 reply(ies), 2 embedded run(s) complete
19:56:24+00:00 info Config valid: ~/.openclaw/openclaw.json

hidden lanceBOT
#

That confirms the queue/backlog diagnosis.

deferring until 4 operation(s), 2 reply(ies), 2 embedded run(s) complete means your config change is valid, but Telegram can’t reload yet because OpenClaw is still finishing active/queued agent turns. So any Telegram setting change won’t take effect until those runs drain.

Fastest unblock:

/stop

Send /stop in the affected Telegram chats/topics, especially the overflowing topic:1, then wait a few seconds. If it still doesn’t drain, restart the gateway:

openclaw gateway restart

After it comes back, do either /compact or /new in that huge topic before continuing. Otherwise it may immediately hit context overflow again and recreate the backlog.

fervent python
#

I hit new in all, and forced tge restart

hidden lanceBOT
#

Good — that should clear the worst session pressure.

After restart, check whether it actually came back clean:

openclaw status --all
openclaw logs --follow

Then send one tiny test message in two different Telegram topics. What we want to see:

  • no new context-overflow-diag
  • no big event_loop_delay warnings
  • no queued=... growing
  • replies use topic-scoped sessions like telegram:group:<chat>:topic:<id>

If it’s still slow immediately after /new + restart, the next suspect is either Telegram preview/edit throttling or gateway CPU saturation. For that test, temporarily turn Telegram streaming off and restart once:

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

If that fixes it, we know the slowdown is the Telegram streaming/throttler path rather than session context.