CRON Jobs from Telegram and Discord Chat | Friends of the Crustacean 🦞🤝 | Page 1

charred hemlock Apr 19, 2026, 12:44 PM

#

Is it Possible to setup CRON jobs via Telegram chat. It keeps going into a Tool loop and then goes to Heartbead.md

I

harsh jettyBOT Apr 19, 2026, 12:44 PM

#

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

fallow quailBOT Apr 19, 2026, 12:44 PM

#

hoary compassBOT Apr 19, 2026, 12:46 PM

#

Let me check the actual docs and cron behavior so I don’t guess.

#

Yes, that should be possible.

Telegram is just the chat surface, the actual scheduler runs in the Gateway. So “set up a cron from Telegram chat” is supported in principle. Docs: https://docs.openclaw.ai/automation/cron-jobs and https://docs.openclaw.ai/channels/telegram

If it keeps bouncing into HEARTBEAT.md, that usually means one of these:

it took the main-session / next-heartbeat path instead of an isolated cron path
the model is getting stuck in a tool loop while trying to call cron
cron is disabled / the Gateway is not staying up

Most useful next checks, please paste these:

openclaw --version
openclaw status --all
openclaw cron list

#

Then reproduce it once and grab logs:

openclaw logs --follow

If you’re using a local/Ollama-style model, I’d also test once with a more tool-reliable cloud model, because tool loops there are a pretty common cause.

Also worth knowing: if the run is going through HEARTBEAT.md, that’s not really “Telegram cron delivery”, that’s the heartbeat/main-session route. For a clean scheduled message back to chat, you usually want isolated cron + announce delivery, not heartbeat.

If you paste the version + status + a short log snippet around the loop, I can narrow it down pretty fast.

#

That log helps. I’m checking what OpenClaw uses that handshake for before I guess.

#

That log is useful, and it points at a Gateway WebSocket handshake problem, not a cron syntax problem.

handshake timeout ... 127.0.0.1 -> 127.0.0.1:18789 means:

something on the same machine did reach the Gateway
but it never finished the WS connect/auth handshake within the timeout
then the socket closed before connect

So yes, Telegram-created cron jobs should be possible, but this looks more like the client/runtime path is stalling before the cron tool flow completes, which can absolutely lead to weird fallback behavior like ending up back in HEARTBEAT.md.

Please paste these next:

openclaw --version
openclaw status
openclaw gateway status

#

openclaw doctor
openclaw channels status --probe

Then reproduce once with:

openclaw logs --follow

and paste 20-30 lines around the timeout, especially anything mentioning:

connect.challenge
connect failed
unauthorized
tool loop

#

cron

Two likely buckets from here:

Gateway/client handshake issue on localhost
Model tool-calling issue after that, especially if you’re using a local/Ollama-style model

Docs for the relevant pieces:

If you send the status output, I can narrow it down a lot faster.

#

This narrows it down a lot.

Your Gateway itself looks healthy, so this does not look like “cron can’t run on Telegram” or “scheduler is down”.

What jumps out is this:

Agents: Bootstrapping: 2
earlier you also had a localhost WS handshake timeout

That combo makes me think the cron request is getting derailed by agent bootstrap / local connect issues, not by Telegram.

Two important bits:

Bootstrapping is supposed to be first-run only
BOOTSTRAP.md should be removed when it finishes: https://docs.openclaw.ai/start/bootstrapping

So if you’re already set up and still have 2 bootstrapping agents, that’s suspicious.

#

I’d check these next

1. See if BOOTSTRAP.md is still hanging around

Test-Path "$HOME/.openclaw/workspace/BOOTSTRAP.md"

2. Check channel health

openclaw channels status --probe

3. Reproduce once while tailing logs

openclaw logs --follow

#

Then paste the lines around the failure, especially anything containing:

tool loop
cron
bootstrapping
connect.challenge
connect failed

If `BOOTSTRAP.md` still exists and onboarding is already done

I’d try moving it aside, then restarting the gateway:

Move-Item "$HOME/.openclaw/workspace/BOOTSTRAP.md" "$HOME/.openclaw/workspace/BOOTSTRAP.md.bak"

#

openclaw gateway restart

One more likely cause

If you’re using a local/Ollama-style model, test once with a cloud model too. Tool loops around cron are much more common there.

So, short version: yes, Telegram cron should work on your setup, and right now I’m more suspicious of stuck bootstrapping than cron itself. If you paste the Test-Path result + the next log chunk, I can probably tell you the exact next move.

hoary compassBOT Apr 19, 2026, 1:54 PM

#

I’ve got enough to be more specific now, checking whether this is a known Windows/local-loopback path before I send you down the wrong rabbit hole.

#

Yep, this makes it much clearer.

This is not a Telegram-side problem and probably not a cron syntax problem either.

Your log says the failure is:

local loopback only (127.0.0.1 -> 127.0.0.1)
the Gateway is reached
but the client never finishes the WS connect handshake
so the connection gets closed before connect

So the issue is basically: something local is stalling before the cron/tool flow can complete.

Given your earlier status, the two things I’m most suspicious of are:

stuck bootstrapping
Windows local loopback handshake/client stall

#

Also, the fact you still had 2 bootstrapping agents is not normal once setup is done. BOOTSTRAP.md is supposed to go away after first run: https://docs.openclaw.ai/start/bootstrapping

I’d do this next, in this order

1) Check for leftover bootstrap file

Test-Path "$HOME/.openclaw/workspace/BOOTSTRAP.md"

If that returns True and you’re already past onboarding, move it aside:

Move-Item "$HOME/.openclaw/workspace/BOOTSTRAP.md" "$HOME/.openclaw/workspace/BOOTSTRAP.md.bak"

Then restart:

#

openclaw gateway restart

2) Run doctor

openclaw doctor

3) Reproduce once with logs

openclaw logs --follow

and paste the next chunk if it still fails.

#

So my current read is:

Yes, cron-via-Telegram should be possible
No, your current failure does not look like “Telegram can’t create cron jobs”
it looks more like local gateway handshake + stuck bootstrap state

If BOOTSTRAP.md is still there, I’d bet on that being the first real fix to try.

If that still doesn’t clear it, I’d start treating this as a bug and file it here with the exact logs + version: https://github.com/openclaw/openclaw/issues

charred hemlock Apr 19, 2026, 1:55 PM

#

I have removed the Bootstrap.md and restarted then these wore the new logs still the same issue

charred hemlock Apr 19, 2026, 7:29 PM

#

@hoary compass export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN"
openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN --dry-run
openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json
openclaw gateway

openclaw channels login --channel whatsapp --account work

Give me exact commands for Discord Multi agent set up

I keep getting this error Channel login failed: Error: Channel discord does not support login

hoary compassBOT Apr 19, 2026, 7:31 PM

#

Let me verify the exact Discord config shape so I don’t hand you made-up keys.

#

Yep, that error is expected.

Discord does not support channels login.
channels login is for channels like WhatsApp. For Discord you use bot tokens + channels add or config, then pair DMs if you want DM access.

Also, on Windows PowerShell, use $env:..., not export.

Exact commands, Discord multi-agent, PowerShell

1) Set bot tokens

$env:DISCORD_BOT_TOKEN = "YOUR_DEFAULT_BOT_TOKEN"
$env:DISCORD_BOT_TOKEN_WORK = "YOUR_WORK_BOT_TOKEN"

2) Add Discord accounts

#

openclaw channels add --channel discord --name "Main Bot" --token $env:DISCORD_BOT_TOKEN
openclaw channels add --channel discord --account work --name "Work Bot" --token $env:DISCORD_BOT_TOKEN_WORK
openclaw config set channels.discord.defaultAccount default --strict-json
openclaw config set channels.discord.enabled true --strict-json

3) Add the second agent

main already exists, so just add the extra one:

openclaw agents add work --workspace ~/.openclaw/workspace-work --non-interactive

4) Bind Discord accounts to agents

#

openclaw agents bind --agent main --bind discord:default
openclaw agents bind --agent work --bind discord:work

5) Restart and verify

openclaw gateway restart
openclaw channels status --probe
openclaw agents list --bindings

If you want Discord DMs too

DM each bot once, then approve pairing:

#

openclaw pairing list discord
openclaw pairing approve --channel discord <CODE>

openclaw pairing list --channel discord --account work
openclaw pairing approve --channel discord --account work <CODE>

Important

Do not run this for Discord:

openclaw channels login --channel discord

That command is unsupported for Discord.

#

Docs

If you want, next I can give you the exact guild/server allowlist commands too, so both bots can reply inside your Discord server channels, not just DMs.

charred hemlock Apr 20, 2026, 1:08 AM

#

@hoary compass Add agents, accounts, and bindings

Add agents under agents.list, channel accounts under channels.<channel>.accounts, and connect them with bindings (examples below).

Give me actual command for discord bindings

hoary compassBOT Apr 20, 2026, 1:09 AM

#

Yep, the actual CLI binding commands for Discord are these.

Bind Discord accounts to agents

Default Discord account -> `main`

openclaw agents bind --agent main --bind discord:default

Named Discord account `work` -> agent `work`

openclaw agents bind --agent work --bind discord:work

Another named account `coding` -> agent `coding`

#

openclaw agents bind --agent coding --bind discord:coding

If you only have one Discord account

You can do:

openclaw agents bind --agent main --bind discord

But I’d use discord:default explicitly, it’s clearer.

Check what got written

#

openclaw agents bindings
openclaw agents list --bindings

Remove a Discord binding

openclaw agents unbind --agent work --bind discord:work

What these commands create in config

{
  bindings: [

#

    { agentId: "main", match: { channel: "discord", accountId: "default" } },
    { agentId: "work", match: { channel: "discord", accountId: "work" } },
    { agentId: "coding", match: { channel: "discord", accountId: "coding" } }
  ]
}

So the short answer is:

discord:default = default Discord bot/account
discord:work = Discord account id work
discord:coding = Discord account id coding

Docs: https://docs.openclaw.ai/cli/agents and https://docs.openclaw.ai/concepts/multi-agent

If you want, I can give you the full exact sequence from zero for:

#

add Discord accounts
add agents
bind them
verify routing

charred hemlock Apr 20, 2026, 1:12 AM

#

Agents:

main (default)
Identity: 🔴 (the red pill, naturally) Morpheus (IDENTITY.md)
Workspace: ~.openclaw\Morpheus
Agent dir: ~.openclaw\agents\main\agent
Model: ollama/kimi-k2.5:cloud
Routing rules: 0
Routing: default (no explicit rules)
Providers:
- Discord default: configured
- Discord work (Trinity): configured
- Telegram default: configured
- Telegram trinity: configured
work
Identity: 🔷 Trinity (IDENTITY.md)
Workspace: ~.openclaw\Trinity
Agent dir: ~.openclaw\agents\work\agent
Model: ollama/kimi-k2.5:cloud
Routing rules: 1
Routing: Telegram trinity
Providers:
- Telegram trinity: configured
  Routing rules:
- telegram accountId=trinity

my cron job outputs are all getting posted and royted throught he main agent. @hoary compass give me exact command to fix this. Is this binding issue ?

hoary compassBOT Apr 20, 2026, 1:13 AM

#

Yes, this looks like a binding issue.

Right now main has no explicit rules, so it becomes the fallback for anything not explicitly bound.
Your work agent is only bound to telegram:trinity, so Discord work is still falling through to main.

Exact commands to fix your current setup

Bind the missing Discord account to work:

openclaw agents bind --agent work --bind discord:work

Make the default accounts explicit on main too:

#

openclaw agents bind --agent main --bind discord:default --bind telegram:default

Verify:

openclaw agents list --bindings

Why this matters

With your current setup, routing is effectively:

telegram:trinity -> work
everything else -> main

#

After the fix, it should be:

telegram:default -> main
discord:default -> main
telegram:trinity -> work
discord:work -> work

Important for existing cron jobs

If the cron jobs were already created while routing was wrong, they may still be pinned wrong.

So for any existing job that should belong to work, patch it too:

If the job should deliver via Discord work

openclaw cron edit <JOB_ID> --agent work --channel discord --account work

#

If the job should deliver via Telegram trinity

openclaw cron edit <JOB_ID> --agent work --channel telegram --account trinity

List jobs first if needed:

openclaw cron list

So the short answer is:

Yes, the missing discord:work binding is part of the problem
Also, existing cron jobs may need --agent and --account fixed

If you want, send me the output of:

#

openclaw agents list --bindings
openclaw cron list

and I’ll tell you the exact cron edit commands for each job.

charred hemlock Apr 20, 2026, 11:55 AM

#

@hoary compass all cron jobs are goin undelivered. [cron:88324160-a94e-4b50-a61f-b3d9bc984298] skipping stale delivery scheduled at 2026-04-20T05:00:59.971Z, started 405m late, current age 407m

hoary compassBOT Apr 20, 2026, 11:56 AM

#

Let me check the exact stale-delivery behavior so I don’t guess at the threshold.

#

That specific log is not mainly a binding issue.

It means OpenClaw did run the job too late, then intentionally refused to post an outdated result:

scheduled for 05:00
actually started 405 minutes late
stale-delivery cutoff is 3 hours
so delivery was skipped on purpose

So this part is a lateness/backlog problem, not just routing.

What it usually means

One of these is happening:

the Gateway/PC was asleep or offline
a previous run got stuck/tool-looped and later cron jobs queued behind it

#

you have enough work queued that jobs are starting hours late

Given your earlier tool-loop issue, I’d honestly suspect queue backlog from stuck runs.

Exact commands

Re-run the missed job now

openclaw cron run 88324160-a94e-4b50-a61f-b3d9bc984298

Inspect this job’s run history

openclaw cron runs --id 88324160-a94e-4b50-a61f-b3d9bc984298 --limit 20

Check overall gateway health

#

openclaw status --deep
openclaw gateway status

Important

If the machine sleeps, cron on Windows will absolutely end up “late”, and OpenClaw may skip stale delivery instead of dumping old messages hours later.

So the short read is:

binding issues explain wrong agent/account routing
this stale-delivery message means the job started far too late

If you paste:

#

openclaw cron runs --id 88324160-a94e-4b50-a61f-b3d9bc984298 --limit 20

I can tell you whether it’s sleep/offline time, or one stuck run blocking the queue.

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/automation/cron-jobs

charred hemlock Apr 20, 2026, 9:22 PM

#

@hoary compass 24 [telegram] [telegram] Group migrated: "The Matrix" -5281611781 → -1003990813367
22:18:24 [telegram] [telegram] No config found for old group ID -5281611781, migration logged only
22:18:24 [telegram] [telegram] Group migrated: "The Matrix" -5281611781 → -1003990813367
22:18:24 [telegram] [telegram] No config found for old group ID -5281611781, migration logged only

will this cause errors in Telegram channel meeages. Commands to fix ?

hoary compassBOT Apr 20, 2026, 9:23 PM

#

Let me verify the Telegram migration behavior so I can give you the safe fix, not folklore.

#

That log by itself is not automatically an error.

It means Telegram migrated the group ID:

old: -5281611781
new: -1003990813367

and OpenClaw checked whether it had explicit config under the old group ID, but found none, so it just logged it.

Short answer

No, this won’t break Telegram messages by itself.
It only becomes a problem if you still have the old chat ID referenced somewhere, for example in:

channels.telegram.groups
channels.telegram.defaultTo
channels.telegram.accounts.<id>.defaultTo

#

cron jobs using --to <old-chat-id>

Commands to check

openclaw config get channels.telegram.groups
openclaw config get channels.telegram.defaultTo
openclaw config get channels.telegram.accounts.trinity.defaultTo
openclaw cron list

If you see the old ID -5281611781 anywhere, replace it with the new one -1003990813367.

Exact fix commands

If `defaultTo` still uses the old group ID

#

openclaw config set channels.telegram.defaultTo "-1003990813367"

If your `trinity` Telegram account uses the old group ID

openclaw config set channels.telegram.accounts.trinity.defaultTo "-1003990813367"

If a cron job still targets the old group ID

openclaw cron edit <JOB_ID> --channel telegram --to "-1003990813367"

My read of your log

Because it says:

#

No config found for old group ID ... migration logged only

that usually means there was nothing explicit to migrate, so this is often just informational.

If you want, paste the outputs of:

openclaw config get channels.telegram.groups
openclaw cron list

and I’ll tell you exactly whether anything still points at the old ID.

charred hemlock Apr 21, 2026, 1:32 AM

#

@hoary compass LM Studio is not responsing what comand to increase this google/gemma-4-e4b] The number of tokens to keep from the initial prompt is greater than the context length (n_keep: 11222>= n_ctx: 4096). Try to load the model with a larger context length, or provide a shorter input.. Error Data: n/a, Additional Data: n/a

#

@hoary compass LM Studio is not responsing what comand to increase this google/gemma-4-e4b] The number of tokens to keep from the initial prompt is greater than the context length (n_keep: 11222>= n_ctx: 4096). Try to load the model with a larger context length, or provide a shorter input.. Error Data: n/a, Additional Data: n/a

hoary compassBOT Apr 21, 2026, 1:37 AM

#

If LM Studio is just too slow to start responding, increase the LLM idle timeout:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 600 --strict-json

If you also want the whole agent run to have more time:

openclaw config set agents.defaults.timeoutSeconds 1800 --strict-json

Then restart the gateway:

openclaw gateway restart

#

Also worth checking first:

openclaw --version

One important gotcha: if LM Studio is unloaded / cold-starting, it can look like it’s hanging. Keep the model loaded in LM Studio.

And bluntly, if this is for cron + tool use, local models often still tool-loop even with bigger timeouts. In that case it’s more a model/tool reliability problem than a timeout problem.

Docs:

If you want, paste your LM Studio model config and I’ll tell you whether you should raise timeout, disable tool support, or switch that cron to a hosted model.

#

That error is different, let me verify the exact knob so I don’t hand you the wrong fix.

#

Ah, that’s not a timeout issue. It’s a context window issue.

Your model got loaded with:

n_ctx: 4096

but OpenClaw tried to send roughly:

n_keep: 11222

So the fix is to increase the LM Studio model context length, not the response timeout.

Command to increase it

First inspect your LM Studio model entries:

#

openclaw config get models.providers.lmstudio.models

Then set a bigger context window for the Gemma entry, for example:

openclaw config set models.providers.lmstudio.models[0].contextWindow 32768 --strict-json

Then restart:

openclaw gateway restart

Easier path

#

You can also just rerun:

openclaw onboard

Choose LM Studio again, then set a higher preferred load context length when it asks.

Important

If LM Studio / that Gemma build only supports 4096, then you can’t really fix this with OpenClaw alone. You’ll need either:

a model/build with a much larger context window, or
a lighter runtime:

#CRON Jobs from Telegram and Discord Chat

I’d check these next

If BOOTSTRAP.md still exists and onboarding is already done

One more likely cause

I’d do this next, in this order

1) Check for leftover bootstrap file

2) Run doctor

3) Reproduce once with logs

Exact commands, Discord multi-agent, PowerShell

1) Set bot tokens

2) Add Discord accounts

3) Add the second agent

4) Bind Discord accounts to agents

5) Restart and verify

If you want Discord DMs too

Important

Docs

Bind Discord accounts to agents

Default Discord account -> main

Named Discord account work -> agent work

Another named account coding -> agent coding

If you only have one Discord account

Check what got written

Remove a Discord binding

What these commands create in config

Exact commands to fix your current setup

Why this matters

Important for existing cron jobs

If the job should deliver via Discord work

If the job should deliver via Telegram trinity

What it usually means

Exact commands

Re-run the missed job now

Inspect this job’s run history

Check overall gateway health

Important

Short answer

Commands to check

Exact fix commands

If defaultTo still uses the old group ID

If your trinity Telegram account uses the old group ID

If a cron job still targets the old group ID

My read of your log

Command to increase it

Easier path

Important

If `BOOTSTRAP.md` still exists and onboarding is already done

Default Discord account -> `main`

Named Discord account `work` -> agent `work`

Another named account `coding` -> agent `coding`

If `defaultTo` still uses the old group ID

If your `trinity` Telegram account uses the old group ID