telegram stuck but I can chat directly via web | Friends of the Crustacean 🦞🤝 | Page 1

severe pier Apr 15, 2026, 7:41 AM

#

Telegram was working fine just another day and this morning it's ignoring my messages. the messages are being "read" but no response. If I chat via web dashboard it's working fine. how do I debug this?

weary sandalBOT Apr 15, 2026, 7:44 AM

#

Since web chat still works, I’d debug this as a Telegram channel/policy issue, not a model issue.

First, please grab your version:

openclaw --version

Then run this exact ladder:

openclaw status
openclaw channels status --probe
openclaw pairing list telegram
openclaw logs --follow

#

While logs --follow is open, send one Telegram message and watch what shows up.

What I’d look for in the logs:

mention required → group mention gating is dropping it
pairing required / pending approval → DM sender is no longer authorized
Forbidden, 401/403, missing_scope → Telegram auth/permission problem
Telegram API/network errors → reachability issue to api.telegram.org
no visible chat error, but logs show failures → check whether channels.telegram.errorPolicy is set to silent

Two very common Telegram gotchas here:

If this is a group chat, and you expect replies without @botname, check:
- requireMention
- BotFather /setprivacy
- then remove + re-add the bot after changing privacy mode

#

If this started after an upgrade, group auth may be the culprit:
- DM pairing does not authorize group chatting
- make sure the group is allowed in channels.telegram.groups
- and your numeric Telegram user ID is in allowFrom / groupAllowFrom if needed

If the normal logs are too thin, turn on Telegram-specific diagnostics temporarily:

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw logs --follow

Docs:

If you paste:

#

openclaw --version
openclaw channels status --probe
and the relevant logs --follow lines from one failed message

…I can usually tell you the exact cause pretty fast.

severe pier Apr 15, 2026, 7:50 AM

#

openclaw pairing list telegram
07:50:03 [plugins] memory-lancedb-pro: smart extraction enabled (LLM model: gpt-4o-mini, noise bank: ON)
07:50:03 [plugins] memory-lancedb-pro@1.1.0-beta.9: plugin registered (db: /root/.openclaw/memory/lancedb-pro, model: text-embedding-3-small, smartExtraction: ON)
07:50:03 [plugins] memory-lancedb-pro: diagnostic build tag loaded (memory-lancedb-pro-diag-20260308-0058)
07:50:03 [plugins] session-strategy: using none (plugin memory-reflection hooks disabled)

🦞 OpenClaw 2026.4.14 (323493f) — Type the command with confidence—nature will provide the stack trace if needed.

No pending telegram pairing requests.

#

I am sending telegram DMs and they are ignored

weary sandalBOT Apr 15, 2026, 7:51 AM

#

Nice, that rules out the obvious DM pairing issue.

Next I’d do these two:

openclaw channels status --probe
openclaw logs --follow

Then, with logs --follow running, send one Telegram message that gets ignored.

At this point the most likely buckets are:

group mention gating: logs say mention required
Telegram privacy mode: especially if this is a group and you expect replies without @botname
group allowlist/auth: after newer releases, group auth is stricter, so groups / allowFrom / groupAllowFrom may be the issue
silent error replies: bot is failing, but channels.telegram.errorPolicy: "silent" hides the error in chat

#

Telegram send/network failure: logs show Telegram API errors / 401 / 403 / fetch failures

If this is a group chat, tell me one thing too: should the bot respond to plain messages, or only when mentioned?
That changes the top suspect a lot.

If you paste:

openclaw channels status --probe
the relevant openclaw logs --follow lines from one failed message

…I can narrow it down pretty quickly.

severe pier Apr 15, 2026, 7:51 AM

#

07:43:56+00:00 info Gateway reachable.

Slack default: enabled, not configured, stopped, error:not configured
Slack main: enabled, configured, running, connected, bot:config, app:config, works
Slack public: enabled, configured, running, connected, bot:config, app:config, works
telegram default: enabled, configured, running, mode:webhook, bot:@TippBot, token:*** groups:unmentioned, works, audit ok

Warnings:

telegram default: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. (In BotFather run /setprivacy → Disable for this bot (then restart the gateway).)
Run: openclaw doctor

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
07:46:40+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 90ms conn=704641d1…5c3

weary sandalBOT Apr 15, 2026, 7:52 AM

#

Got it, DMs changes the suspect list.

For Telegram DMs, the big suspects are:

channels.telegram.allowFrom is set
- if that exists, it becomes the only auth source
- pairing is ignored
- if it still has @username instead of your numeric Telegram ID, upgrades can break it
- fix: use numeric ID, or try:
```
openclaw doctor --fix
```
reply send is failing
- Telegram API/network/auth error
- or channels.telegram.errorPolicy: "silent" is hiding the failure

severe pier Apr 15, 2026, 7:52 AM

#

I am using webhooks for telegram

weary sandalBOT Apr 15, 2026, 7:52 AM

#

routing/session weirdness
- less common, but logs will show it quickly

The next two commands I’d want are still:

openclaw channels status --probe
openclaw logs --follow

Then send one DM to the bot and watch the logs.

For DM failures, I’d specifically look for:

allowFrom / authorization skip
pairing required
401 / 403 / Forbidden
Telegram send/fetch errors

#

any message skip reason right after inbound receipt

If you have an allowlist config, check these keys first:

channels.telegram.dmPolicy
channels.telegram.allowFrom
channels.telegram.errorPolicy

And if you paste:

openclaw channels status --probe
the logs --follow lines from one ignored DM
whether channels.telegram.allowFrom is set

…I can probably pinpoint it fast.

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

severe pier Apr 15, 2026, 7:53 AM

#

openclaw channels status --probe

🦞 OpenClaw 2026.4.14 (323493f) — Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

07:52:57 [plugins] memory-lancedb-pro: smart extraction enabled (LLM model: gpt-4o-mini, noise bank: ON)
07:52:57 [plugins] memory-lancedb-pro@1.1.0-beta.9: plugin registered (db: /root/.openclaw/memory/lancedb-pro, model: text-embedding-3-small, smartExtraction: ON)
07:52:57 [plugins] memory-lancedb-pro: diagnostic build tag loaded (memory-lancedb-pro-diag-20260308-0058)
07:52:57 [plugins] session-strategy: using none (plugin memory-reflection hooks disabled)
│
◇
Gateway reachable.

Slack default: enabled, not configured, stopped, error:not configured
Slack main: enabled, configured, running, connected, bot:config, app:config, works
Slack public: enabled, configured, running, connected, bot:config, app:config, works
telegram default: enabled, configured, running, mode:webhook, bot:@TippBot, token:config, groups:unmentioned, works, audit ok

Warnings:

telegram default: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. (In BotFather run /setprivacy → Disable for this bot (then restart the gateway).)
Run: openclaw doctor

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

#

@weary sandal wdyt?

weary sandalBOT Apr 15, 2026, 8:06 AM

#

My money is on post-ingress auth or reply failure, not Telegram transport.

Why:

pairing list telegram shows nothing pending
channels status --probe says Telegram is configured, running, works, audit ok
web dashboard chat works
Telegram messages are being seen/read

So the stack looks healthy up to “message arrived”, and the failure is probably after that.

My ranking of likely causes:

channels.telegram.allowFrom / dmPolicy
- if allowFrom is set, pairing is ignored
- stale @username entries are a known footgun after upgrades
- if that’s in play, openclaw doctor --fix is worth trying

#

channels.telegram.errorPolicy: "silent"
- bot is erroring, but Telegram never shows the failure
send-side Telegram API failure
- inbound works, reply send fails
- logs will show 401/403/fetch/network-type errors
less likely: weird per-chat/session issue
- still possible, but logs should expose it

So, bluntly: I do not think this is “Telegram webhook broken”.
I think it’s either DM authorization config or a silent reply error.

If you paste one openclaw logs --follow snippet from a failed DM, I can probably call it pretty confidently.

severe pier Apr 15, 2026, 8:07 AM

#

I don't get anything in the logs

weary sandalBOT Apr 15, 2026, 8:07 AM

#

Ah, that is the big clue.

If a Telegram DM produces nothing at all in openclaw logs --follow, then my read changes a lot:

OpenClaw is probably not receiving the inbound update
and Telegram Bot API has no read receipts, so “read” is not a reliable signal that the gateway saw it

Also, because your channel is in mode:webhook, channels status --probe mostly tells us the bot/token side is healthy, not that inbound webhook delivery is actually reaching your gateway.

So I’d stop chasing pairing/allowlists for a moment and focus on the webhook path.

Most likely now:

stale/bad channels.telegram.webhookUrl
reverse proxy stopped forwarding to the local Telegram webhook listener
webhook secret/path mismatch
webhook registration got wedged and needs re-registration

#

Fastest next steps:

openclaw gateway restart
openclaw status --deep
openclaw doctor

Then test one DM again.

And specifically check these config bits, redacting secrets before pasting anything:

channels.telegram.webhookUrl
channels.telegram.webhookPath
channels.telegram.webhookSecret
channels.telegram.webhookHost
channels.telegram.webhookPort

#

Relevant doc detail: webhook mode normally listens on 127.0.0.1:8787 and default path is /telegram-webhook, so if your public endpoint/proxy changed, Telegram can silently post somewhere OpenClaw never sees.

If you want the fastest binary test, temporarily switch off webhook mode and let Telegram use long polling. If DMs immediately start working, you’ve confirmed it’s the webhook/proxy side.

So, bluntly: with no logs at all, my money is now on webhook ingress, not DM auth.

severe pier Apr 15, 2026, 8:16 AM

#

I have

  "webhookUrl": "https://xxxx.net/telegram-webhook",
  "webhookSecret": "xxx"

tailscale funnel status

Funnel on:

https://xxxx.net/
https:/xxxx.net (Funnel on)
|-- / proxy http://127.0.0.1:8787/

weary sandalBOT Apr 15, 2026, 8:16 AM

#

That config shape actually looks sane to me.

Because Funnel proxies / to http://127.0.0.1:8787/, a request to:

https://xxxx.net/telegram-webhook

should land on OpenClaw’s local Telegram webhook listener just fine.

So the next thing I’d want is Telegram’s own view of the webhook, not more guessing.

Run this, with your real bot token:

curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getWebhookInfo"

Please paste the result, especially:

#

url
pending_update_count
last_error_date
last_error_message

That will tell us fast whether Telegram is:

posting to the right URL
getting 4xx/5xx/timeouts
queuing updates because delivery is broken

My current read:

your Funnel mapping looks okay
if you still get zero local logs, the most likely issue is Telegram is failing to deliver to the webhook, and getWebhookInfo should expose it

Also worth doing once if you haven’t already:

#

openclaw gateway restart

That forces OpenClaw to re-init the Telegram channel and webhook registration path.

So, next best move:

restart gateway
getWebhookInfo
paste the JSON

That should move this from “hmm” to “ah, there it is.”

severe pier Apr 15, 2026, 8:18 AM

#

{"ok":true,"result":{"url":"https://xxxxnet/telegram-webhook","has_custom_certificate":false,"pending_update_count":11,"max_connections":40,"ip_address":"xxxx","allowed_updates":["message","edited_message","channel_post","edited_channel_post","inline_query","chosen_inline_result","callback_query","shipping_query","pre_checkout_query","poll","poll_answer","my_chat_member","chat_join_request","chat_boost","removed_chat_boost","message_reaction","business_connection","business_message","edited_business_message","deleted_business_messages","purchased_paid_media","managed_bot"]}}

weary sandalBOT Apr 15, 2026, 8:18 AM

#

Yep, this pretty strongly points to webhook delivery being broken.

The key signal is:

pending_update_count: 11

If OpenClaw were actually receiving Telegram webhook posts, that number should usually stay near 0. So Telegram is queuing updates and they’re not being consumed.

Also, one thing jumps out:

earlier you showed https://xxxx.net/telegram-webhook
getWebhookInfo shows https://xxxxnet/telegram-webhook

If that missing dot is real and not just redaction, that’s the bug.

I’d do a clean webhook reset:

#

curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/deleteWebhook?drop_pending_updates=false"

curl -F "url=https://xxxx.net/telegram-webhook" \
     -F "secret_token=<YOUR_WEBHOOK_SECRET>" \
     "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/setWebhook"

Then:

openclaw gateway restart
curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getWebhookInfo"

What you want after that:

#

the url matches exactly
pending_update_count starts draining
new Telegram DMs finally show up in logs

So my current diagnosis is:

not pairing
not model/runtime
not Telegram token
very likely wrong/stale webhook registration or webhook ingress failure

If you want, paste the next getWebhookInfo result after resetting it, and I’ll sanity-check it.

severe pier Apr 15, 2026, 8:25 AM

#

actually slack channel does not work

previously it ignored me and now I see this
08:24:28+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=c1f4259d-2fe2-495e-a817-21f49617fc58 sessionId=509c387a-12f9-4fa9-8eec-e81b7cee0293 stopReason=stop payloads=0 — surfacing error to user
Agent couldn't generate a response. Please try again.

#

okay it now responded... telegram still stuck after I've removed webhook

weary sandalBOT Apr 15, 2026, 8:26 AM

#

Ah, yep, this changes the diagnosis.

That warning is not a Slack bug and not really a Telegram bug either. It means the embedded agent/model run ended without producing any visible reply:

stopReason=stop
payloads=0

So the core problem is now: the model/runner is sometimes returning an empty turn.

That fits your symptoms a lot better:

Telegram looked “ignored”
Slack also fails
now you finally got the generic surfaced error

So I’d stop focusing on channels as the root cause. The webhook backlog may still need cleanup, but it’s not the whole story.

What I’d do next:

#

Grab the log lines just before that warning
- OpenClaw logs an earlier line like:
  - empty response detected ... provider=.../...
  - or empty response retries exhausted ...
- that line is the gold, because it tells us which provider/model actually returned nothing
Run:

openclaw models status
openclaw logs --follow

then reproduce once and paste about 20 lines around the failure, especially anything just before:

incomplete turn detected

#

My current read is:

channel transport is not the main bug
the agent is getting an empty model response and eventually surfacing:
Agent couldn't generate a response. Please try again.

If you can paste the few log lines immediately before that warning, we can probably narrow it to:

provider issue
auth/quota issue
empty-response bug
or a bad fallback/profile path

That’s actually progress, weirdly enough, because now we’re looking at the real layer.

#

That’s actually a really useful datapoint.

If it now responded elsewhere, but Telegram is still stuck even after removing the webhook, then the webhook theory is only half the story.

Two things need to be true for Telegram to really switch over cleanly:

OpenClaw restarted and now shows mode:polling
Telegram itself no longer has a webhook registered

So I’d check exactly these:

openclaw gateway restart
openclaw channels status --probe
curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getWebhookInfo"

#

What I want to see:

channels status --probe → Telegram says mode:polling
getWebhookInfo → url is empty

If the webhook is still set on Telegram’s side, clear it explicitly:

curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/deleteWebhook?drop_pending_updates=false"

Then test one DM again.

So my current guess is:

the core agent issue was at least partly transient
Telegram may still be stuck because the mode switch didn’t fully happen

#

or Telegram still has the old webhook registered even though you removed it from config

If you paste:

the new channels status --probe
the new getWebhookInfo

…I can tell you pretty quickly whether Telegram is really in polling mode or still half-stuck on webhook.

severe pier Apr 15, 2026, 8:29 AM

#

it's still webhook mode...

weary sandalBOT Apr 15, 2026, 8:29 AM

#

Ah, then that’s the smoking gun.

If it’s still webhook mode, then OpenClaw is still loading a webhookUrl from somewhere. Removing it didn’t hit the config the gateway is actually using.

I’d check this next:

openclaw gateway status
rg -n "webhookUrl|webhookSecret" ~/.openclaw/openclaw.json

What I’d specifically look for:

channels.telegram.webhookUrl
channels.telegram.accounts.default.webhookUrl
any duplicate Telegram account block still setting webhook mode

#

Also important: openclaw gateway status shows which config the daemon is likely using. If you edited one file but the service is reading another, you’ll keep chasing ghosts.

So the sequence should be:

confirm the actual config path
remove all Telegram webhookUrl entries from that config
restart gateway
re-run:

openclaw channels status --probe

Only once that says mode:polling does the webhook question go away.

So yeah, right now I’d stop debugging Telegram delivery and just fix the config source mismatch first.

severe pier Apr 15, 2026, 8:30 AM

#

okay polling now works and I started getting responses

weary sandalBOT Apr 15, 2026, 8:30 AM

#

Nice, that confirms it. 🎉

So the Telegram issue was basically webhook mode / webhook config, not pairing or DM auth.
If polling works immediately, I’d leave it on polling for now and only revisit webhook after checking the public ingress path end-to-end.

If you want to try webhook again later, I’d verify:

the exact loaded config file
channels.telegram.webhookUrl only exists where you expect
getWebhookInfo matches exactly
Funnel/proxy is really forwarding the webhook path

If Slack is still weird, that’s probably a separate issue from the Telegram one.

Glad we caught it. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

severe pier Apr 15, 2026, 8:31 AM

#

⚠️ Cron job "daily-briefing-afternoon" failed: cron: job execution timed out

how do I increase timeout?

weary sandalBOT Apr 15, 2026, 8:32 AM

#

Yep, for a cron agent job you want the per-job timeout override:

openclaw cron edit <job-id> --timeout-seconds 1800

So for 30 minutes, set 1800.
If your job id is actually daily-briefing-afternoon, then:

openclaw cron edit daily-briefing-afternoon --timeout-seconds 1800

If you’re not sure of the id:

#

openclaw cron list

Then you can inspect recent runs with:

openclaw cron runs --id <job-id> --limit 10

Docs:

If it keeps timing out even after bumping the timeout, the prompt is probably doing too much in one turn, and I’d split the briefing into smaller steps.

severe pier Apr 15, 2026, 8:33 AM

#

I want to change the default

#telegram stuck but I can chat directly via web