Is bot going to sleep?? | Friends of the Crustacean 🦞🤝 | Page 1

frosty laurelBOT Mar 1, 2026, 1:41 AM

#

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

edgy hawkBOT Mar 1, 2026, 1:44 AM

#

What you’re describing usually isn’t the agent “going to sleep” — it’s either:

the agent is still working but Telegram stops showing progress (common when you rely on Telegram “preview streaming” via message edits), or
the run is timing out / erroring, and the only reason it “continues” after you ask again is because your new message kicks off a fresh run that can pick up from state.

1) First: confirm it’s not a Telegram streaming/edit problem

Telegram “live preview” works by sendMessage + lots of editMessageText. If edits start failing (rate limits, message too long, HTML parse errors, network hiccups), the preview can stall and it looks like the bot stopped.

Reproduce once while tailing logs and watch for Telegram send/edit errors:

openclaw logs --follow

Also grab the basics (helps spot timeouts / channel disconnects):

openclaw --version

#

openclaw status --all
openclaw channels status --probe

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

2) Make progress visible (recommended fix)

For Telegram, you have two good options:

Option A — Use Telegram preview streaming (single message that updates)

Set:

channels.telegram.streaming: "partial"

Docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-message-edits
(See also streaming overview: https://docs.openclaw.ai/concepts/streaming)

#

Option B — Prefer block streaming (multiple messages, fewer edits)

This tends to be more reliable for long replies because it doesn’t depend on endless message edits.

From the streaming docs, the relevant knobs are:

agents.defaults.blockStreamingDefault: "on"
agents.defaults.blockStreamingBreak: "text_end" (streams as it goes)
and enable block streaming for Telegram (channels.telegram.blockStreaming: true)

Streaming doc (block streaming + config keys): https://docs.openclaw.ai/concepts/streaming

3) If it’s actually stopping (not just “quiet”): check timeouts

OpenClaw enforces an agent runtime timeout (default is 600s) via:

agents.defaults.timeoutSeconds

If your tasks regularly take longer (big browser flows, long execs, huge prompts), bump that and see if the “stall then resume when prompted” disappears.

(Again, logs will usually show an abort/timeout if this is the cause.)

#

4) Quick “alive” signal while it works (nice-to-have)

Even with streaming, tool-heavy tasks can be quiet. On Telegram you can enable an ack reaction and/or earlier typing indicators:

Telegram ack reaction: channels.telegram.ackReaction (docs are in the Telegram channel page)
Typing behavior: agents.defaults.typingMode (docs: https://docs.openclaw.ai/concepts/typing-indicators)

If you paste (a) your openclaw --version and (b) the log lines from openclaw logs --follow right when it goes quiet (especially any Telegram editMessageText / network errors), I can tell you which of the above is the real root cause in your setup.

sterile forum Mar 1, 2026, 1:53 AM

#

How do I send editMessageText?

edgy hawkBOT Mar 1, 2026, 1:53 AM

#

In Telegram, editMessageText is the raw Telegram Bot API method. In OpenClaw you usually don’t call it directly — OpenClaw uses edits internally for preview streaming.

If your goal is “keep updating me while it works”

Turn on Telegram preview streaming in config:

channels.telegram.streaming: "partial"

Docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-message-edits
(Streaming overview: https://docs.openclaw.ai/concepts/streaming)

That makes OpenClaw send a temporary message and keep editing it as the agent generates output.

If you actually want to edit a Telegram message yourself (from a skill/plugin/agent tool call)

Use OpenClaw’s messaging action edit on the telegram channel (this maps to Telegram edit behavior):

#

{
  action: "edit",
  channel: "telegram",
  target: "123456789",   // chat id
  messageId: "42",       // message id to edit
  message: "New text"
}

Notes:

You can only edit messages that the bot sent (Telegram restriction).
The CLI openclaw message edit is documented as Discord/Slack-only (so don’t be surprised if it doesn’t work for Telegram from the CLI). CLI doc: https://docs.openclaw.ai/cli/message

If you meant “how do I call Telegram’s API directly?”

Telegram Bot API example (outside OpenClaw):

#

POST https://api.telegram.org/bot<token>/editMessageText with chat_id, message_id, text.

If you tell me which one you mean (OpenClaw tool vs direct Telegram API), and whether you’re doing it from a skill or the CLI, I can give the exact command/snippet for that path.

sterile forum Mar 1, 2026, 1:55 AM

#

I meant in reference to what you were asking me to do to test why it seems to stop responding.

edgy hawkBOT Mar 1, 2026, 1:55 AM

#

Yep — the “test” I was trying to get you to do is basically: reproduce the stall while watching the Gateway logs, so we can tell whether the agent is still running, timed out, or Telegram delivery/editing failed.

Here’s a clean, minimal way to do that:

1) Reproduce with logs running

On the machine where the Gateway runs:

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Now, with logs --follow still open, send a Telegram message that normally “starts then goes quiet”.

When it goes quiet, don’t poke it yet — look at what the logs are doing for the next ~30–60 seconds.

#

What we’re trying to see in the logs

You’ll usually fall into one of these buckets:

Telegram edit/send errors (common if preview streaming is on)
- Look for errors mentioning telegram, editMessageText, 429, “Too Many Requests”, parse/HTML errors, etc.
- This means the agent might still be fine, but the streaming preview updates are failing.
Agent timeout / abort
- Look for timeoutSeconds, aborted, run error, etc.
- Then the “status?” message is effectively starting a new run that continues from session context.
Tool stuck / waiting on something
- You’ll see a tool start, but never end (browser/exec/node/tool approval).
- Then the agent is blocked and not producing output.

If you paste just the relevant error lines + ~20 lines around them (and redact anything that looks like a token), we can diagnose fast.

#

Docs ladder for reference: https://docs.openclaw.ai/gateway/troubleshooting

2) Optional: force “I’m alive” output so it doesn’t feel asleep

Even if nothing is “wrong”, long runs can be silent unless you enable streaming.

A) Telegram preview streaming (edits one message as it generates)

Set in config:

{
  channels: {
    telegram: {
      streaming: "partial",
    },
  },
}

Docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-message-edits

#

B) Block streaming (sends chunks as separate messages — usually more robust)

This is often more reliable than lots of edits:

{
  agents: {
    defaults: {
      blockStreamingDefault: "on",
      blockStreamingBreak: "text_end",
    },
  },
  channels: {
    telegram: {
      blockStreaming: true,
    },
  },

#

Streaming doc (keys/behavior): https://docs.openclaw.ai/concepts/streaming

After any config change:

openclaw gateway restart

If you answer these two, I can point to the most likely fix immediately:

Is channels.telegram.streaming currently on (partial/block/progress), or off?
When it “goes quiet”, does openclaw logs --follow show an error, or does it look like it’s still actively doing tool calls?

sterile forum Mar 1, 2026, 1:58 AM

#

The log doesn't show anything about what is happening in Telegram. No entries get added.

edgy hawkBOT Mar 1, 2026, 1:59 AM

#

If openclaw logs --follow shows zero new lines while you’re sending Telegram messages, one of these is true:

you’re tailing the wrong gateway (CLI is pointed at a different gateway.remote.url than the instance that’s connected to Telegram), or
your gateway is running, but file logging is set so high that it’s not recording anything useful (or file logging is going somewhere else), or
Telegram messages aren’t reaching the gateway at all (so nothing to log).

Step 1 — confirm you’re watching the right gateway + where logs live

Run and paste (safe output; redacts secrets):

openclaw --version
openclaw status --all
openclaw channels status --probe

status --all will usually make it obvious whether you’re in local vs remote mode and which gateway you’re actually talking to.

Step 2 — turn up the file log level (this is the big one)

#

By default, a lot of “message received / body” stuff is debug, so you won’t see Telegram activity at info.

Set file logs to debug, restart, then reproduce:

openclaw config set logging.level "debug"
openclaw gateway restart
openclaw logs --follow

Now send a Telegram message and see if logs start moving.

When you’re done debugging, turn it back down (otherwise logs get noisy):

openclaw config set logging.level "info"
openclaw gateway restart

#

Docs: https://docs.openclaw.ai/gateway/logging

Step 3 — if logs still don’t move at all

Then it’s almost certainly “wrong gateway” or “no file logs”.

To confirm quickly: while openclaw logs --follow is running, in another terminal run:

openclaw doctor

If even that doesn’t add log lines, your file logger is probably pointing somewhere unexpected (check logging.file), or you’re connected to a different gateway than you think.

If you paste the status --all output, I can tell you which case you’re in.

sterile forum Mar 1, 2026, 2:10 AM

#

Logs still aren't moving. How can I see if there are multiple gateways and which one I'm connecting to? There should only be one gateway, correct?

edgy hawkBOT Mar 1, 2026, 2:10 AM

#

You usually run one Gateway per machine/profile, but it’s absolutely possible to end up with two by accident (most common: the daemon/service is running, and you also started openclaw gateway manually in a terminal; or your CLI is in remote mode pointing at a different host).

To see what gateways exist and which one your CLI is talking to, these are the high-signal commands:

1) List all reachable gateways (this answers your question directly)

openclaw gateway probe

This command always probes:

your configured remote gateway (if any), and
localhost even if remote is configured

…and if multiple are reachable, it prints them all. (There’s also --json if you want pasteable output.)

Docs: https://docs.openclaw.ai/cli/gateway#gateway-probe

#

2) See the installed service + probe result (is the daemon gateway alive?)

openclaw gateway status --deep

Look for:

Runtime: running
RPC probe: ok
the probe URL it’s using

Docs: https://docs.openclaw.ai/cli/gateway#gateway-status

3) Check if your CLI is in remote mode (common “wrong gateway” cause)

openclaw config get gateway.mode
openclaw config get gateway.remote.url

#

If gateway.mode is remote, then openclaw logs --follow is tailing the remote gateway’s file logs — which would explain why nothing changes when you’re actually interacting with a different gateway.

Docs: https://docs.openclaw.ai/gateway/remote

What I’d like you to paste back

Paste the output of:

openclaw gateway probe
openclaw gateway status --deep

From that, we can pinpoint:

whether you have 2 gateways,
which one Telegram is connected to,
and why openclaw logs --follow is “stuck” (usually: CLI is pointed at the other gateway, or the RPC probe is failing).

sterile forum Mar 1, 2026, 2:16 AM

#

Here are the commands and status: openclaw gateway probe

🦞 OpenClaw 2026.2.26 (bc50708)
I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
◇
Gateway Status
Reachable: yes
Probe budget: 3000ms

Discovery (this machine)
Found 3 gateway(s) via Bonjour (local.)

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (25ms) · RPC: ok
Gateway: FRIDAY (192.168.#.###) · linux 6.17.0-14-generic · app 2026.2.23
Wide-area discovery: unknown

will@FRIDAY:~$ openclaw gateway status --deep

🦞 OpenClaw 2026.2.26 (bc50708) — Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-02-28.log
Command: /usr/bin/node /home/will/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (Error: systemctl --user unavailable: Failed to connect to bus: No medium found)
RPC probe: ok

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
will@FRIDAY:~$ openclaw config get gateway.mode

🦞 OpenClaw 2026.2.26 (bc50708) — Claws out, commit in—let's ship something mildly responsible.

local

edgy hawkBOT Mar 1, 2026, 2:18 AM

#

You can have multiple gateways. Most people run one, but nothing stops you from having:

one gateway in a container + another on the host,
one you started manually + one started by a service/supervisor,
or other machines on your LAN advertising gateways (your probe already found 3 via Bonjour).

For Telegram specifically: you really want exactly one OpenClaw instance polling for a given bot token. If two gateways are running Telegram long-polling with the same token, they can “steal” updates from each other, which looks exactly like “it goes to sleep until I poke it”.

1) Find all gateways on your network (not just the one you connected to)

You already ran gateway probe (good). Now run discovery to actually list the 3 beacons:

openclaw gateway discover --timeout 4000
# or
openclaw gateway discover --json

#

That will show you which other hosts are advertising OpenClaw gateways.

Docs: https://docs.openclaw.ai/cli/gateway#gateway-discover

2) Confirm which gateway your CLI is actually talking to

From your output, your CLI is connecting to:

ws://127.0.0.1:18789 (probe target)
and that gateway reports app 2026.2.23 even though your CLI is 2026.2.26

That version mismatch usually means: you updated OpenClaw, but the running gateway process is still the old build and hasn’t been restarted yet.

So: restart the gateway process you’re actually running (since systemd user services aren’t available in your environment, it’s likely a foreground process / container supervisor restart).

3) Prove whether Telegram is running on this gateway (super important)

On FRIDAY, run:

#

openclaw channels status --probe

You should see a Telegram section that looks “connected / polling / ok”. If Telegram isn’t shown as running/healthy there, then the Telegram bot you’re chatting with is almost certainly being handled by one of the other gateways you discovered — which also explains why your logs “don’t move”.

4) Why `openclaw logs --follow` might look dead

Two quick sanity checks:

A) Is the file actually changing? (bypass RPC)

ls -lt /tmp/openclaw/openclaw-*.log | head
tail -f /tmp/openclaw/openclaw-2026-02-28.log

B) Is your file log level too high to show useful channel traffic?

#

openclaw config get logging.level

If you paste the output of:

openclaw gateway discover --timeout 4000
openclaw channels status --probe

…I can tell you immediately whether this is a “multiple gateways fighting over Telegram updates” situation (my top suspect) or a pure logging/version/restart issue.

sterile forum Mar 1, 2026, 2:28 AM

#

openclaw gateway discover --json
{
"timeoutMs": 2000,
"domains": [
"local."
],
"count": 1,
"beacons": [
{
"instanceName": "FRIDAY (OpenClaw)",
"displayName": "FRIDAY",
"host": "openclaw.local",
"port": 18789,
"txt": {
"transport": "gateway",
"tailnetDns": "name.text.ts.net",
"displayName": "FRIDAY",
"lanHost": "openclaw.local",
"gatewayPort": "18789",
"role": "gateway"
},
"lanHost": "openclaw.local",
"tailnetDns": "name.text.ts.net",
"gatewayPort": 18789,
"role": "gateway",
"transport": "gateway",
"domain": "local.",
"wsUrl": "ws://openclaw.local:18789"
}
]
}
will@FRIDAY:~$ openclaw channels status --probe

🦞 OpenClaw 2026.2.26 (bc50708) — Meta wishes they shipped this fast.

│
◇
Gateway reachable.

Telegram default: enabled, configured, running, in:34h ago, out:46h ago, mode:polling, bot:@FRIDAYbot, token:config, groups:unmentioned, works, audit ok

edgy hawkBOT Mar 1, 2026, 2:29 AM

#

That output is super revealing:

gateway discover shows only one Bonjour-advertised gateway (FRIDAY) ✅
but channels status --probe says Telegram was last in: 34h ago / out: 46h ago ❗

If you’re actively using Telegram “mostly”, those timestamps should be updating constantly. So right now, the gateway you’re connected to (ws://127.0.0.1:18789 on FRIDAY) is not seeing your Telegram traffic.

That also explains why openclaw logs --follow “doesn’t move”: you’re tailing the gateway that isn’t receiving the Telegram updates you’re testing with.

Should there only be one gateway?

Best practice: yes, one active gateway per Telegram bot token.

Telegram “polling” (getUpdates) is effectively a single-consumer queue. If you have another OpenClaw instance (or any other script) polling the same bot token somewhere else (VPS, old laptop, container, etc.), it can steal updates and you’ll get weird “goes quiet until I poke it” behavior.

And that “other gateway” might not show up in Bonjour discovery (Bonjour is optional / LAN-only).

Quick 2-minute proof: is THIS gateway actually the one your Telegram chat hits?

#

A) Send yourself a message from the gateway host

On FRIDAY run (use your Telegram @username):

openclaw message send --channel telegram --target @YOUR_USERNAME --message "ping from openclaw CLI"

If you don’t receive it in Telegram: Telegram outbound from this gateway isn’t working (wrong token/account, channel not actually running, etc.).
If you do receive it: outbound is fine.

B) Reply to that message in Telegram, then immediately re-run:

openclaw channels status --probe

If it still says in: 34h ago, then your Telegram replies are being processed by something else (another gateway / another poller), not this one.

If it’s another poller, how to find it

#

On any machines/containers where you might have run OpenClaw before (including VPS), look for another running gateway:

another terminal/tmux session running openclaw gateway
docker container with openclaw
a second host with the same channels.telegram.botToken

On FRIDAY you can also sanity-check:

ps aux | grep -i openclaw

(You’re looking for more than one gateway process.)

One more important detail: version mismatch

Your CLI is 2026.2.26 but the gateway reports app 2026.2.23 in gateway probe. That usually means the gateway process hasn’t been restarted since you updated OpenClaw. Once we’re sure which gateway is “the real one”, restart that gateway.

#

If you paste:

the result of the openclaw message send ... test (did it arrive?), and
the updated openclaw channels status --probe right after you reply in Telegram,

…I can tell you conclusively whether you have “two pollers fighting” vs a pure gateway/channel config issue.

sterile forum Mar 1, 2026, 2:35 AM

#

can we just shutdown all gateways and start only one?

edgy hawkBOT Mar 1, 2026, 2:36 AM

#

Yes — and for Telegram it’s a good idea, because only one process should be long-polling (getUpdates) for a given bot token. Two gateways polling the same token will “steal” updates from each other and you’ll see exactly the flaky / “needs waking up” behavior.

That said: you don’t necessarily need to shut down every gateway everywhere — you mainly need to ensure only one gateway has Telegram enabled / is polling.

Safer approach (recommended): keep gateways, disable Telegram everywhere except one

On every other machine/container where OpenClaw might be running, set:

openclaw config set channels.telegram.enabled false
# then restart that gateway

This avoids breaking other channels/nodes you might still want on those machines.

If you really want “stop everything and start only one”

Do this in order:

#

1) Pick the “real” gateway host (sounds like FRIDAY)

Start/restart the gateway there (however you normally run it — tmux/docker/etc). Then verify Telegram is actively receiving:

openclaw channels status --probe

When you send a Telegram message to the bot, that in: … ago should update to seconds/minutes.

2) Find other gateways (they might not show up in Bonjour)

On every machine where you’ve ever run OpenClaw (laptop/VPS/old box/container), run:

openclaw gateway status --deep
openclaw channels status --probe

#

If you see Telegram “running, mode: polling” on more than one machine — that’s your culprit.

3) Stop the extra gateways

How you stop depends on how they’re run:

If it’s a foreground process: stop the terminal / tmux session running openclaw gateway.
If it’s docker: stop that container.
If it’s a service: openclaw gateway stop (or systemctl ... depending on how it was installed).

In your FRIDAY output, systemd user services are unavailable, so openclaw gateway stop/start likely won’t work there — you’re probably running it under some other supervisor (or foreground). That’s fine; just means “stop it” is whichever method you used to start it.

Key point

You don’t have to eliminate multiple gateways globally — you just must ensure exactly one gateway is polling Telegram for @FRIDAYbot.

If you tell me where else you might have run OpenClaw (VPS? laptop? docker?), I can give you the exact “stop” command for that environment.

sterile forum Mar 1, 2026, 2:37 AM

#

The send message didn't work it gave me Error: Telegram recipient @eewill40 could not be resolved to a numeric chat ID (Call to 'getChat' failed! (400: Bad Request: chat not found)) but I know that eewill40 exists.

edgy hawkBOT Mar 1, 2026, 2:37 AM

#

That error is expected for Telegram DMs.

Why `--target @eewill40` fails

Telegram’s Bot API can’t reliably resolve a person (private chat) by @username unless the bot already “knows” that chat, and in general bots can’t initiate a DM to a user who hasn’t started the conversation with the bot.

So getChat(@eewill40) → 400: chat not found usually means: from the bot’s perspective, there is no known chat with that username.

The correct way to test sending a DM

From the account you want to DM (eewill40), open your bot (@FRIDAYbot) in Telegram and press Start, then send “hi”.
Now you need the numeric chat id (or the numeric from.id). You can get it either via logs or via Telegram’s getUpdates:

Option A (preferred): from OpenClaw logs

Temporarily set debug logging (so inbound Telegram envelopes show up):
```
openclaw config set logging.level "debug"
```

#

Restart your gateway process (however you run it), then:
```
openclaw logs --follow
```
Send a DM again in Telegram and look for chat.id / from.id.

Option B: from Telegram Bot API directly (no OpenClaw logs needed)
On the gateway host (don’t paste the token into Discord):

curl "https://api.telegram.org/bot<BOT_TOKEN>/getUpdates"

Send a DM to the bot, re-run the command, and read:

message.chat.id (that’s the DM target)
message.from.id (same number for DMs)

Then send using the numeric ID:

#

openclaw message send --channel telegram --target <NUMERIC_CHAT_ID> --message "ping"

Important: your earlier `channels status --probe` showed `in: 34h ago`

That strongly suggests this gateway still isn’t receiving Telegram updates, which points back to the “another poller is stealing updates” problem (or wrong token on this host). If getUpdates never shows your new messages, you almost certainly have another process somewhere polling the same bot token.

If you tell me whether getUpdates shows the message after you DM the bot, we’ll know immediately whether the issue is:

“another poller stealing updates” (getUpdates stays empty / doesn’t show your DM), or
“this gateway is the poller, just logging/resolution confusion” (getUpdates shows it).

sterile forum Mar 1, 2026, 2:45 AM

#

I try to find the channel ID but the log isn't updating so I use the curl command and get this <html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

edgy hawkBOT Mar 1, 2026, 2:46 AM

#

That 301 Moved Permanently HTML is almost certainly because you hit Telegram over http (or your curl isn’t following redirects). Telegram’s Bot API will 301 redirect http://api.telegram.org/... → https://api.telegram.org/....

Try these exact tests (and please don’t paste your bot token into Discord):

1) Confirm you can reach Telegram API over HTTPS (and token is valid)

TOKEN='123456:ABC...'   # keep this local; don't paste it here

curl -sS -L "https://api.telegram.org/bot$TOKEN/getMe"

You should get JSON like: {"ok":true,"result":{...}}

If that still returns HTML/301, run:

curl -sS -I "https://api.telegram.org/bot$TOKEN/getMe"

#

and check what the Location: header points to (if any).

2) Get the DM chat id (after you /start the bot and send “hi”)

Send a message to your bot in Telegram, then:

curl -sS -L "https://api.telegram.org/bot$TOKEN/getUpdates" | jq '.result[-1].message.chat.id'

If getUpdates stays empty even after you DM the bot, that’s the smoking gun for “another process is consuming the updates” (another OpenClaw gateway / script polling the same bot token somewhere). That also fits your earlier channels status --probe showing in: 34h ago.

Why this matters for your original “bot goes quiet” problem

If two gateways poll the same token, Telegram updates get split unpredictably → one gateway starts a task, then the next user message lands on the other gateway, which “wakes it up”.

If you tell me what you get from getMe (just ok true/false, no token) and whether getUpdates shows your DM, we’ll know whether this is:

network/redirect issue, or

#

definitely multiple pollers fighting (most likely).

sterile forum Mar 1, 2026, 2:50 AM

#

It's null

edgy hawkBOT Mar 1, 2026, 2:51 AM

#

null from that jq '.result[-1].message.chat.id' usually means one of these:

getUpdates returned an empty result array ([]) → there are no updates available to read (often because another process is consuming them), or
the last update exists, but it’s not a message update (could be my_chat_member, etc.), so .message is missing.

Let’s make this deterministic.

1) Check what Telegram is actually returning (safe to paste)

Run (don’t paste your token, but the output is safe):

curl -sS "https://api.telegram.org/bot$TOKEN/getUpdates" | jq '{ok, resultCount: (.result|length), last: .result[-1]}'

Interpret:

resultCount: 0 ⇒ Telegram has no updates available for your bot token at that moment.
resultCount > 0 but last doesn’t contain message ⇒ your earlier jq path was just too specific.

#

2) Extract the latest DM chat id robustly

After you DM the bot (“hi”), run:

curl -sS "https://api.telegram.org/bot$TOKEN/getUpdates" \
| jq -r '.result[] | select(.message) | .message.chat.id' \
| tail -n 1

That prints a numeric chat id if Telegram is delivering your DM updates to this token.

3) Check if a webhook is set (webhook blocks polling)

curl -sS "https://api.telegram.org/bot$TOKEN/getWebhookInfo" | jq .

If you see a non-empty "url": "https://...", then polling behavior gets weird depending on your setup.

#

To clear it (safe):

curl -sS "https://api.telegram.org/bot$TOKEN/deleteWebhook?drop_pending_updates=true" | jq .

4) If `resultCount` stays 0 even after you DM the bot

That’s the smoking gun: something else is consuming updates for this bot token.

This matches your OpenClaw status earlier: Telegram ... in:34h ago — your active Telegram chats are going to another poller, not this gateway.

In that case, the fix is:

find the other OpenClaw instance / script / container using the same bot token and stop it, OR
disable Telegram on all other gateways (channels.telegram.enabled: false) so only one polls.

If you paste the output of step (1) and (3) (redact nothing needed—those don’t include your token), I can tell you immediately which branch you’re in.

sterile forum Mar 1, 2026, 2:55 AM

#

How do I shut down all gateways completely and start only one gateway. I'm not sure why I have multiple gateways but I don't think I need them.

edgy hawkBOT Mar 1, 2026, 2:55 AM

#

You can, but there are two different “multiple gateway” problems:

Multiple gateways on the same machine/port → only one can listen on 127.0.0.1:18789 anyway, so this is usually easy to fix.
Multiple machines/processes polling the same Telegram bot token → this is the real cause of “Telegram goes quiet / needs waking up”. Even if you “start only one gateway”, it won’t help unless the other poller is stopped (or you rotate the token).

Below is the clean “shut everything down and run one” plan, plus the “nuclear but effective” Telegram fix.

A) On FRIDAY: make sure you have only ONE gateway process locally

Since your systemd --user isn’t available, your gateway is almost certainly being run in a terminal/tmux/docker.

1) See what’s listening on the gateway port

ss -ltnp | grep 18789 || true
# or

#

lsof -nP -iTCP:18789 -sTCP:LISTEN

If you see a PID, stop that process (the safest way is to stop the tmux session / docker container it’s running in). If you must:

kill <PID>

2) Start ONE gateway (and auto-kill any leftover listener on that port)

openclaw gateway --force

--force is specifically meant to kill an existing listener on the selected port before starting.

Docs: https://docs.openclaw.ai/cli/gateway#run-the-gateway

#

B) On every other machine/container: stop OpenClaw gateways (if they exist)

You only need to do this on machines where you’ve ever installed/run OpenClaw.

1) If it’s installed as a service

Try:

openclaw gateway stop
openclaw gateway status --deep

2) If it’s a foreground process

Look for it:

ps aux | grep -i openclaw | grep -i gateway

#

ss -ltnp | grep 18789 || true

Then stop that process/session/container.

3) If it’s Docker

docker ps | grep -i openclaw
# then
docker stop <container>

C) The Telegram-specific “make it impossible for another poller to steal updates” fix (recommended)

If you’re not sure where the other poller is, the fastest way to guarantee there’s only one is:

#

Rotate the Telegram bot token in BotFather

In Telegram, talk to @BotFather and revoke/regenerate the token for @FRIDAYbot (BotFather provides a command to revoke/regenerate).

Then update the token on FRIDAY (channels.telegram.botToken) and restart the gateway.

This instantly breaks any other gateway/script that was polling with the old token, which is exactly what you want right now.

After that, verify on FRIDAY:

openclaw channels status --probe

Send the bot a DM and confirm the in: … ago time updates to seconds/minutes.

One important footgun

Repeatedly calling Telegram getUpdates manually via curl consumes updates (it’s the same queue OpenClaw polls). So don’t run getUpdates in a loop while testing—use openclaw channels status --probe to see whether your gateway is receiving messages.

#Is bot going to sleep??