Telegram Bot API 409 Conflict: Fix 'terminated by other getUpdates request' (2026)

Β· Updated
telegram bot apiopenclawtelegram409 conflictgetupdates +1

If your Telegram bot logs show this exact error, you have a polling ownership conflict:

409 Conflict: terminated by other getUpdates request

Quick answer

The same Telegram bot token is being used by two or more getUpdates clients. Stop every duplicate bot process, container, service, VPS instance, development session, or automation that uses that token. Then start exactly one polling process.

For OpenClaw, the shortest safe recovery flow is:

openclaw gateway stop
ps -ef | grep -Ei "openclaw|telegram" | grep -v grep
# Stop any duplicate process or deployment you find.
openclaw gateway start
openclaw logs --follow

This error is defined by Telegram Bot API long polling behavior: getUpdates must not be called concurrently for the same bot. The fix applies to OpenClaw, Python libraries such as python-telegram-bot or aiogram, Node.js bots, Docker, systemd, PM2, Kubernetes, and custom polling scripts.

This guide gives you a practical flow: contain β†’ find cause β†’ stabilize.

1) Contain first: keep only one OpenClaw instance running

Check current state:

openclaw status
openclaw gateway status
openclaw logs --follow

If 409 errors keep looping, stop Gateway first:

openclaw gateway stop

Then verify no stale processes are still alive:

ps -ef | grep -i openclaw | grep -v grep

If any are still running, kill the extra PID(s):

kill <PID>

Start once, and only once:

openclaw gateway start
openclaw gateway status

2) Root cause A (most common): same bot token on multiple machines

Typical pattern:

Result: they keep kicking each other out.

Quick verification

Run on each machine:

openclaw gateway status
openclaw logs | tail -n 50

Keep only one long-running node online. Stop and disable the other:

openclaw gateway stop
systemctl --user disable --now openclaw 2>/dev/null || true

3) Check for a webhook conflict β€” a different 409 message

An active webhook can also block polling, but it normally produces a different error similar to:

Conflict: can't use getUpdates method while webhook is active

That is not the same as terminated by other getUpdates request. Check it separately if your logs mention a webhook.

Check webhook status:

export TELEGRAM_BOT_TOKEN='replace-with-your-token'
curl "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getWebhookInfo"

If url is not empty, delete the webhook:

curl "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/deleteWebhook?drop_pending_updates=false"

Then restart OpenClaw:

openclaw gateway restart

4) Root cause C: systemd + manual start = duplicate runtime

You may have installed OpenClaw as a service, then also started it manually.

Check service status:

systemctl --user status openclaw --no-pager

Check duplicate processes:

ps -ef | grep -E "openclaw|gateway" | grep -v grep

Use one model only:

If moving to service-managed mode:

openclaw gateway install
systemctl --user enable --now openclaw
systemctl --user status openclaw --no-pager

5) Docker case: multiple replicas fighting for one token

If you deploy with Docker/Compose or orchestrators, verify replica count.

Rules:

Force single replica during troubleshooting:

docker compose ps
docker compose up -d --scale openclaw=1

For Kubernetes, PM2, or another process manager, apply the same rule: one Telegram polling replica per token. Scaling the web application is fine, but the update consumer must remain a singleton unless you move to Telegram webhooks.

6) Post-fix verification checklist

openclaw status
openclaw gateway status --deep
openclaw channels list
openclaw doctor

Expected:

7) For long-term stability: run OpenClaw on one always-on VPS

If you switch often between local machine and cloud, duplicate startup is easy to trigger. A cleaner pattern:

Practical baseline: 2 vCPU / 2GB RAM.

8) Copy-ready 409 conflict recovery pack

openclaw gateway stop
ps -ef | grep -i openclaw | grep -v grep
export TELEGRAM_BOT_TOKEN='replace-with-your-token'
curl "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getWebhookInfo"
openclaw gateway start
openclaw logs --follow

If the exact terminated by other getUpdates request conflict persists, a second runtime still exists somewhere else. Check another host, container, service manager, staging deployment, development machine, or forgotten script.

Do not repeatedly call deleteWebhook for this exact error unless getWebhookInfo actually shows an active webhook. A competing getUpdates poller is the root cause.

Official Telegram Bot API references

Frequently Asked Questions

What does '409 Conflict: terminated by other getUpdates request' mean?

It means two or more processes are calling Telegram Bot API getUpdates with the same bot token. Telegram long polling supports only one active poller per bot, so a newer request terminates the previous one.

How many getUpdates processes can a Telegram bot run?

Only one long-polling getUpdates process should run for a bot token. If you need multiple application replicas, use one dedicated update consumer and distribute work internally, or switch to a webhook architecture.

Can an old webhook cause this exact 409 error?

Not usually. An active webhook produces a different conflict saying getUpdates cannot be used while a webhook is active. The exact 'terminated by other getUpdates request' message points to another polling client.

How do I fix Telegram 409 in OpenClaw?

Stop every OpenClaw instance using the token, including local, VPS, systemd, Docker, staging, and old test processes. Then start one gateway and confirm the 409 message no longer appears in the logs.

Will rotating the Telegram bot token fix a 409 conflict?

It can disconnect an unknown old poller, but it should be a last resort. First locate duplicate runtimes. If you rotate the token, update the one intended deployment and revoke or stop every old configuration.

Core Guides (Recommended)

Related Posts

Was this article helpful?

πŸ’¬ Comments