OpenClaw Telegram: "Conflict: terminated by other getUpdates request" (409)

Your gateway log shows Conflict: terminated by other getUpdates request and the bot has gone silent. This is Telegram HTTP 409: Telegram allows exactly one getUpdates long-poll to hold the lease for a bot token at a time, so when two clients poll the same token it terminates one of them. Your OpenClaw channel then enters exponential-backoff auto-restart and drops messages during each window. The most common cause is not misconfiguration — it's two pollers overlapping, usually for a few seconds after rapid back-to-back restarts. Before you touch the token or config, the one rule that matters: do not run getUpdates yourself to test the bot — that call counts as a second poller and causes the exact 409 you're chasing. Use getMe and getWebhookInfo (read-only) instead.

[telegram] channel exited: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running
auto-restart attempt 3/10 in 8s

Don't diagnose with getUpdates — it causes the 409

This is the trap that turns a self-healing transient into a reproducible failure. When your bot looks broken, the instinct is to curl Telegram's getUpdates to "see if the token works." Don't. getUpdates opens a long-poll lease, and your running gateway already holds one. The moment your manual call lands, Telegram has two pollers on the token and 409s your gateway's poller offline — so you've just created the failure you were investigating, and the log will keep showing the conflict for as long as you keep poking it.

Use the read-only Telegram Bot API calls, which take no poll lease and are safe to run against a live bot:

• getMe — confirms the token is valid and returns the bot identity. If this returns your bot, the token is fine; stop chasing "wrong token."
• getWebhookInfo — confirms whether a webhook is set. A configured webhook blocks getUpdates polling entirely, which is its own silent-bot cause (covered below). If url is empty, no webhook is interfering.

Neither of those will knock your gateway offline. getUpdates will.

Why the bot looks healthy but answers nothing

This failure is deceptive because every health signal is green: the pod is 2/2 Running, the gateway reports ready, and the Telegram provider logs starting provider (@yourbot) plus isolated polling ingress started. And yet the bot consumes nothing. Messages pile up unconsumed in Telegram's queue, because the only component that drains that queue — the getUpdates poller — keeps getting 409'd off the lease and restarted. Each backoff window is a gap during which inbound messages aren't picked up. So "starting provider" plus "ready" plus dead silence is the exact fingerprint of poller contention, not a bad token and not a crashed agent.

A "gateway says ready but the channel is dead" symptom can have other roots too — if the log shows no 409 conflict at all, read why an OpenClaw Telegram/WhatsApp channel stalls at startup instead. The 409 signature here is specific: repeated conflict and auto-restart lines.

Transient restart overlap vs. a real second poller

There are two distinct causes behind one log line. They look identical for the first minute; the fix is different. Tell them apart by watching the log over about 10 minutes (without calling getUpdates).

Transient: restart overlap (self-heals)

By far the more common case. When you restart a Telegram-connected instance, the old gateway's getUpdates long-poll can still be in flight while the new one starts polling — two pollers on one token for a few seconds. This happens most often when two restarts stack: for example a config-change light restart immediately followed by a manual full restart.

• Tell: the 409s appear in a burst right after a restart, then the log goes clean.
• Fix: stop restarting and wait. If the log stays clean for about 10 minutes — no new conflict lines, and a test message gets answered — it has healed and there's nothing to fix.
• Prevent: leave roughly a minute between restarts of a Telegram instance, so the previous poller's long-poll fully releases before the next one starts.

Persistent: a real second poller (won't self-heal)

If the conflicts keep coming long after the last restart, something else is genuinely holding the token's lease. The same bot token is running in two places:

• A zombie or old pod of the same instance that didn't fully terminate and is still polling.
• The token reused in a second deployment, a staging copy, or a local script you forgot was running.

• Tell: new conflict lines keep arriving with no restart activity to explain them.
• Fix: find the second consumer and shut it down so exactly one process polls the token. Then confirm the log goes clean.

Stop babysitting your OpenClaw box

Fix it once — or stop fixing it for good.

Apply the checklist above and keep self-hosting, or skip the maintenance entirely: run your OpenClaw on managed hosting from $6.90/mo, starting with a 7-day free trial. We handle the stale locks, gateway restarts, version upgrades, and uptime — and you can import your existing instance in a couple of minutes. Cancel anytime.

Managed hosting — from $6.90/mo Your own hosted OpenClaw instance with automatic restarts and version upgrades. Starts with a 7-day free trial — import your current setup, keep your channels, cancel anytime.

$199 managed setup — optional Prefer we do it for you? One workspace configured end-to-end: first-run config, one 30-minute onboarding/debug session, and a 7-day follow-up. Limited weekly slots.

• Managed hosting handles stale .jsonl.lock files, gateway restarts, and version upgrades for you
• Import your existing OpenClaw setup in minutes — keep your channels and configuration
• The optional $199 setup is scoped: no custom development, enterprise/SRE support, or unsupported self-hosting repair

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

Run it on managed hosting — from $6.90/mo Prefer we set it up? $199 managed setup See how managed OpenClaw hosting sequences restarts

Confirm and fix it (self-hosted)

Work from the gateway log, never from getUpdates.

1) Tail the gateway's verbose log

The path follows the pattern /tmp/openclaw/openclaw-*.log. Grep for the relevant lines:

grep -E 'conflict|getUpdates|auto-restart' /tmp/openclaw/openclaw-*.log

2) Read the timeline

If the only 409s line up with your own getUpdates calls and the log is clean afterward, there is no real second poller — it was self-inflicted or a transient restart overlap. Stop poking it.

3) Rule out a webhook

Run getWebhookInfo (safe). A non-empty url means a webhook is set, which blocks getUpdates polling — delete the webhook if you intend to poll.

4) For the persistent case, kill the duplicate

Track down the zombie/old pod or the second process/host using the token and stop it. Ensure exactly one consumer of the token.

5) Confirm it's fixed by message flow, not by health checks

Tail the gateway log and send one message. You should see an inbound line like Inbound message ... -> @yourbot followed by outbound send ok. That round trip — not "ready" — is proof the channel is alive.

A note on the token: a placeholder in config is normal

If you're on managed hosting and you inspect the config, don't be alarmed by what you find. On a managed instance the botToken value in openclaw.json is the literal placeholder ${TELEGRAM_BOT_TOKEN}, and there may be no Telegram token visible in the process environment. This is expected, not a bug. The real token is resolved at runtime from a dotenv file the init container writes. Seeing a placeholder in the config or no token in /proc/<pid>/environ is normal — it is not evidence that your token is wrong, so don't go re-issuing tokens over it. (getMe returning your bot already settled the "is the token valid" question.)

Frequently asked questions

What does "Conflict: terminated by other getUpdates request" mean in OpenClaw Telegram?

It's Telegram HTTP 409. Telegram permits only one getUpdates long-poll per bot token at a time. The message means two clients are polling the same token simultaneously, so Telegram terminated one. In OpenClaw it surfaces as [telegram] channel exited: Conflict: terminated by other getUpdates request, followed by auto-restart attempts.

Why is my OpenClaw Telegram bot showing healthy/ready but not responding to messages?

Because health and message consumption are separate. The pod can be 2/2 Running, the gateway ready, and the provider logging starting provider (@yourbot) while the getUpdates poller keeps getting 409'd off the token's lease and restarted. Nothing drains Telegram's queue during those backoff windows, so messages pile up and the bot looks alive but answers nothing.

Does calling getUpdates to test my bot cause the 409 conflict?

Yes. getUpdates opens a long-poll lease, and your gateway already holds one. Your manual call becomes the second poller and 409s the gateway's poller offline — you create the exact failure you're diagnosing. Use the read-only getMe and getWebhookInfo calls instead; they take no lease.

Is the Telegram 409 getUpdates conflict permanent or does it fix itself?

It depends on the cause. A transient overlap from rapid back-to-back restarts self-heals once the old poller's long-poll releases — clean for about 10 minutes means it's fixed. A persistent conflict, caused by the same token running in two places, will not self-heal until you shut the second poller down.

How do I find the second poller / duplicate instance using my bot token?

Tail the gateway log (/tmp/openclaw/openclaw-*.log, grep conflict|getUpdates|auto-restart) and check whether conflicts keep arriving with no restart activity to explain them — that indicates a real second consumer. Look for a zombie/old pod of the same instance, or the token reused in a second deployment, staging copy, or local script. Ensure exactly one process polls the token.

Does a Telegram webhook block getUpdates polling, and how do I check with getWebhookInfo?

Yes — a configured webhook and getUpdates polling are mutually exclusive; a set webhook blocks polling. Check it with getWebhookInfo (read-only, safe to run against a live bot). If the returned url is non-empty, a webhook is set; delete it if you intend to poll.

How long should I wait between restarting a Telegram-connected OpenClaw instance?

Leave roughly a minute between restarts. That gives the previous gateway's getUpdates long-poll time to release the lease before the next one starts polling, which avoids the overlap that produces the transient 409.