cron: isolated agent run stalled before first model call (last phase: attempt-dispatch) | Friends of the Crustacean 🦞🤝 | Page 1

analog surge May 12, 2026, 1:45 PM

#

since recent update (not sure specifically which) I'm getting this in my telegram as response to cron exec

⚠️ Cron job "Daily Notion Work Digest" failed: cron: isolated agent run stalled before first model call (last phase: attempt-dispatch)

what can caude it and how to fix?

cobalt willowBOT May 12, 2026, 1:45 PM

#

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

upbeat nestBOT May 12, 2026, 1:47 PM

#

That error is the cron watchdog, not the root cause itself.

last phase: attempt-dispatch means the job was picked up and OpenClaw was about to hand the isolated cron turn to the agent/model harness, but it didn’t report progress before the pre-model watchdog fired. In practice that’s usually one of:

mixed/stale processes after an update → Gateway still running old code or wedged child runner
model/auth/provider startup hanging before the first request, especially CLI-backed providers
daemon env mismatch after update (service doesn’t have the same API keys/auth/PATH as your shell)
a stuck/overlapping previous cron run or runner lane congestion
less commonly, a regression in the harness/provider path

First thing: what does this show?

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

#

openclaw cron runs --id <jobId> --limit 20
openclaw cron show <jobId>

Then try the quick fixes:

openclaw doctor
openclaw gateway restart
openclaw cron run <jobId>
openclaw logs --follow

If it still fails, check the model on that cron job. If it uses a CLI-backed provider, try temporarily editing the cron to a known-working cloud model/provider and run it again. If that fixes it, the issue is probably provider auth/CLI startup/env, not cron itself.

Also: increasing the cron job timeout usually won’t fix this specific failure, because the pre-model watchdog is intentionally capped so “stuck before first model call” fails quickly instead of waiting for the full job budget.

#

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

analog surge May 12, 2026, 1:48 PM

#

◇

🦞 OpenClaw 2026.5.7 (eeef486) — You had me at 'openclaw gateway start.'

│
◇
ID Name Schedule Next Last Status Target Delivery Agent ID Model
72387633-52f7-4497-af19-732a8fad5e48 Daily Notion Work Digest cron 0 19 * * 0-4 @ Asia/Jeru... in 2h 16h ago error isolated announce -> telegram:-1003908026480 (explicit) butler -

upbeat nestBOT May 12, 2026, 1:49 PM

#

Thanks — this helps. Two notable things in that row:

Agent ID: butler means the cron is running under that agent, not necessarily your default chat agent.
Model: - means the cron job has no per-job model override. It will resolve from the cron session / butler agent / global default model.

So I’d check whether the butler agent’s default model/auth changed or broke during the update.

Run these next:

openclaw cron runs --id 72387633-52f7-4497-af19-732a8fad5e48 --limit 20
openclaw cron show 72387633-52f7-4497-af19-732a8fad5e48
openclaw status --all

Quick isolation test: force this cron onto a known-working model explicitly, then run it once:

#

openclaw cron edit 72387633-52f7-4497-af19-732a8fad5e48 --model "<the model that works in normal chat>"
openclaw gateway restart
openclaw cron run 72387633-52f7-4497-af19-732a8fad5e48
openclaw cron runs --id 72387633-52f7-4497-af19-732a8fad5e48 --limit 5

If that works, the cron system is probably fine and the culprit is butler’s resolved model/auth/profile. If it still dies at attempt-dispatch, then grab logs around the manual run:

openclaw logs --follow

and look for agent harness selected, auth/profile errors, CLI provider startup, or anything mentioning butler / that cron id.

Also worth doing after an update:

#

openclaw doctor
openclaw gateway restart

Docs note: isolated cron model precedence is per-job model → stored cron-session override → agent/default model, so the - model column pushes us toward checking the butler agent/default config rather than the cron schedule itself. https://docs.openclaw.ai/cli/cron#isolated-cron-model-precedence

analog surge May 12, 2026, 1:51 PM

#

❯ openclaw cron show 72387633-52f7-4497-af19-732a8fad5e48

🦞 OpenClaw 2026.5.7 (eeef486) — iMessage green bubble energy, but for everyone.

│
◇
id: 72387633-52f7-4497-af19-732a8fad5e48
name: Daily Notion Work Digest
enabled: yes
schedule: cron 0 19 * * 0-4 @ Asia/Jerusalem (exact)
session: isolated
agent: butler
model: -
delivery: announce -> telegram:-1003908026480 (explicit)
next: in 2h
last: 16h ago
status: error
diagnostic: cron: isolated agent run stalled before first model call (last phase: attempt-dispatch)

upbeat nestBOT May 12, 2026, 1:51 PM

#

Yep, that confirms it’s failing before the actual model request. The schedule/delivery look fine; the suspicious part is still agent: butler + model: -.

Next useful command is the run history — it may include more diagnostics than show:

openclaw cron runs --id 72387633-52f7-4497-af19-732a8fad5e48 --limit 10

Then I’d do this as a clean repro:

openclaw gateway restart
openclaw cron run 72387633-52f7-4497-af19-732a8fad5e48
openclaw logs --follow

If logs don’t show an obvious provider/auth error, try pinning the cron to a model you know works in normal chat:

#

openclaw cron edit 72387633-52f7-4497-af19-732a8fad5e48 --model "<known-working-model>"
openclaw cron run 72387633-52f7-4497-af19-732a8fad5e48

If pinning the model fixes it, then butler’s default/resolved model or auth profile is the cause. If it still stalls at attempt-dispatch, that smells more like a runner/harness startup bug in 2026.5.7 and is worth filing with the cron runs output + log tail: https://github.com/openclaw/openclaw/issues

analog surge May 12, 2026, 2:16 PM

#

it probably use an issue with rate limit on codex. nows with gemini I have this:
FallbackSummaryError: All models failed (2): google/gemini-2.5-flash: LLM request timed out. (timeout) | google/gemini-2.5-flash-lite: LLM request timed out. (timeout)

which probably a global issue?

upbeat nestBOT May 12, 2026, 2:17 PM

#

That new error is different and actually a little more informative: the cron is now reaching the model layer, but both Gemini attempts timed out:

gemini-2.5-flash: LLM request timed out
gemini-2.5-flash-lite: LLM request timed out

So: possible global/provider issue, but not enough to conclude that. It can also be local/network/API-key/project/quota, or the cron prompt/tool work taking longer than the model request timeout.

Quick checks:

openclaw status --all
openclaw models status
openclaw logs --follow

#

Then run a tiny Gemini prompt outside cron to separate “Gemini broken” from “this cron is heavy”:

openclaw ask --model google/gemini-2.5-flash "Reply with ok"

If tiny prompt times out too → likely Google/provider/network/auth/project issue. Check Google AI Studio / Vertex status + quota, and try another provider temporarily.

If tiny prompt works → the cron run is probably too heavy or hitting a tool/context stall. In that case I’d either:

openclaw cron edit 72387633-52f7-4497-af19-732a8fad5e48 --model "<known-working-stronger-model>"

or simplify the cron prompt / increase the relevant model request timeout if you have one configured.

I tried to do a live web status search from here, but web search isn’t configured in this runtime, so I can’t verify a global outage from my side. 🦞

analog surge May 12, 2026, 2:23 PM

#

what better model in google gemini family?

upbeat nestBOT May 12, 2026, 2:24 PM

#

For a cron digest, I’d avoid the flash-lite tier. It’s great for cheap/simple work, but digests with Notion context + tool use usually want the strongest Gemini Pro-class model your configured Google provider exposes.

Rule of thumb:

Best reliability/quality: use the current Gemini Pro model available in your provider/model list.
Cheaper/faster fallback: Gemini Flash.
Avoid for this job: Flash Lite, unless the prompt is very small.

I’m intentionally not naming exact model IDs because they change quickly and stale IDs cause pain. Check what your install exposes with your model picker/status, or ask in #old-models for current hands-on recommendations.

Docs: https://docs.openclaw.ai/concepts/models

analog surge May 12, 2026, 3:05 PM

#

Will Cron honor the fallback models?

upbeat nestBOT May 12, 2026, 3:06 PM

#

Yes — isolated cron honors fallback models.

The nuance:

If the cron job has --model, that model is the primary for the job.
Configured fallback chains still apply after that primary fails.
If the job payload has its own fallbacks, those replace the configured fallbacks.
If fallbacks: [] is set, the cron run is strict and won’t fall back.
If the selected model can’t be resolved/allowed, cron fails with a validation error rather than silently choosing something else.

So your FallbackSummaryError: All models failed (2) means fallback did happen: it tried gemini-2.5-flash, then gemini-2.5-flash-lite, and both timed out.

Docs: https://docs.openclaw.ai/cli/cron#models

analog surge May 12, 2026, 3:10 PM

#

How can I define it in the job.json?

upbeat nestBOT May 12, 2026, 3:11 PM

#

In ~/.openclaw/cron/jobs.json, put it inside the job’s payload, not top-level.

Shape is:

{
  "version": 1,
  "jobs": [
    {
      "id": "72387633-52f7-4497-af19-732a8fad5e48",
      "name": "Daily Notion Work Digest",
      // ...keep existing fields...
      "payload": {
        "kind": "agentTurn",
        "message": "...keep your existing prompt...",

#

        // optional: job primary model
        "model": "google/<your-preferred-gemini-model>",

        // optional: per-job fallback chain, tried in order
        "fallbacks": [
          "google/<first-fallback>",
          "google/<second-fallback>"
        ]
      }
    }
  ]
}

Important bits:

#

payload.model = primary model for this cron job.
payload.fallbacks = fallback models for this cron job.
payload.fallbacks overrides the agent/global fallback chain.
"fallbacks": [] explicitly disables fallbacks.
Don’t edit jobs-state.json; that’s runtime state.

I’d first dump the exact job so you don’t accidentally lose fields:

openclaw cron get 72387633-52f7-4497-af19-732a8fad5e48

Then edit only the payload block in ~/.openclaw/cron/jobs.json, save, and run:

openclaw doctor

#

openclaw gateway restart
openclaw cron run 72387633-52f7-4497-af19-732a8fad5e48

analog surge May 12, 2026, 3:13 PM

#

If nothing is defined will it use the default agent model and fallbacks?

upbeat nestBOT May 12, 2026, 3:13 PM

#

Yes.

If the job has neither payload.model nor payload.fallbacks, isolated cron resolves like this:

stored cron-session model override, if one exists
the selected agent’s model config — in your case agent: butler
global/default agent model config

And fallbacks come from that same resolved agent/default model config.

So for your job, with model: -, it should use butler’s configured primary + fallbacks, unless the cron session has a stored model override.

If you add only payload.model, cron uses that as the job primary and still applies configured fallbacks. If you add payload.fallbacks, those replace the configured fallbacks for that job.

#cron: isolated agent run stalled before first model call (last phase: attempt-dispatch)