Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix cron run: default 30s timeout kills long-running jobs even when job itself is healthy [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#54320•Fetched 2026-04-08 01:29:05
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
yanmo96yanmo96
Participants
otsengotsengyanmo96yanmo96
Timeline (top)
commented ×1cross-referenced ×1referenced ×1subscribed ×1

Error Message

This creates a false ERROR state: the cron framework records status: error with error: "cron: job execution timed out" even though the isolated session actually completed successfully.

  • Manual trigger (first attempt): openclaw cron run <id> - killed at exactly 30,014ms, status ERROR

Root Cause

The 30s default is hardcoded in the CLI entry point (cron-run.js):

--timeout <ms>   Timeout in ms (default: "30000")

There is no corresponding config flag (cron.runTimeoutMs, cron.defaultTimeout, etc.) to change this default. Users must manually pass --timeout 0 every time.

Fix Action

Fix / Workaround

Workaround (current)

PR fix notes

PR #54328: fix(cli): increase cron run default timeout from 30s to 10min

Description (problem / solution / changelog)

Summary

openclaw cron run <id> had a hardcoded default CLI timeout of 30,000ms (30 seconds) from the shared gateway RPC client. For long-running cron jobs (e.g. backtests), this caused the CLI to exit with a timeout error even when the isolated session completed successfully on the gateway side.

Before: openclaw cron run <id> → 30s → ERROR, job still running
After: openclaw cron run <id> → 10 min → OK, job completes

Changes

1. src/cli/gateway-rpc.ts

Line 18 — CLI option default:

- .option("--timeout <ms>", "Timeout in ms", "30000")
+ .option("--timeout <ms>", "Timeout in ms (0 = no limit)", "600000")

Line 42 — Programmatic fallback (when callGatewayFromCli is invoked without addGatewayClientOptions):

- timeoutMs: Number(opts.timeout ?? 10_000),
+ timeoutMs: Number(opts.timeout ?? 600_000),

2. docs/cli/cron.md

Added a cron run timeout section documenting the --timeout flag and the 600s default, aligned with agents.defaults.timeoutSeconds.

Rationale

  • 600,000ms = 10 minutes — exactly matches agents.defaults.timeoutSeconds (600s), so the CLI now aligns with the agent runtime default
  • The ?? 10_000 fallback was pre-existing and inconsistent even before this PR (10s vs 30s); now it's consistent at 600s
  • All other gateway commands (list, status, rm, etc.) are fast and complete well within 10 minutes

Testing

Manual trigger of a backtest job:

  • openclaw cron run <id> (before fix): ERROR at 30,014ms
  • openclaw cron run <id> --timeout 0 (before fix): OK at 98,359ms

Fixes: openclaw/openclaw#54320

Changed files

  • docs/cli/cron.md (modified, +8/-0)
  • src/cli/gateway-rpc.ts (modified, +2/-2)

Code Example

--timeout <ms>   Timeout in ms (default: "30000")

---

--timeout <ms>   Timeout in ms (default: "0", i.e. no limit)

---

{
  cron: {
    runTimeoutMs: 0,  // default 30000ms for backward compat; 0 = no timeout
  }
}

---

openclaw cron run <id> --timeout 0

---

alias cronrun="openclaw cron run --timeout 0"
RAW_BUFFERClick to expand / collapse

Problem

openclaw cron run <id> has a hardcoded default timeout of 30,000ms (30 seconds) in the CLI. There is no config flag to override this default.

Impact: Manually triggering long-running cron jobs via the CLI times out at 30s even when:

  • The job has payload.timeoutSeconds set correctly (e.g. 900s)
  • The isolated session is healthy and completes successfully in ~90-100s
  • The scheduled (non-manual) execution works correctly

This creates a false ERROR state: the cron framework records status: error with error: "cron: job execution timed out" even though the isolated session actually completed successfully.

Evidence

A multi-step weekly backtest job was used as a test case:

  • Manual trigger (first attempt): openclaw cron run <id> - killed at exactly 30,014ms, status ERROR
  • Manual trigger (second attempt): openclaw cron run <id> --timeout 0 - ran for 98,359ms (~98s), status OK
  • Scheduled (Sunday 6pm): No timeout issue - isolated session completes naturally in ~98s every time

Root Cause

The 30s default is hardcoded in the CLI entry point (cron-run.js):

--timeout <ms>   Timeout in ms (default: "30000")

There is no corresponding config flag (cron.runTimeoutMs, cron.defaultTimeout, etc.) to change this default. Users must manually pass --timeout 0 every time.

Impact Summary

Trigger methodTimeout behaviorWorks around
Scheduled (gateway-triggered)No CLI cap - waits for sessionFine
Manual cron run <id>Hard 30s CLI capUse --timeout 0
sessions_spawn (subagents)agents.defaults.subagents.runTimeoutSeconds (default 0 = no timeout)Fine

Only the cron run CLI command is affected.

Proposed Fix

Option A (simplest): Change the default to --timeout 0 (no timeout) in the CLI:

--timeout <ms>   Timeout in ms (default: "0", i.e. no limit)

Manual runs would now wait indefinitely, matching scheduled run behavior.

Option B (safer): Add a config flag cron.runTimeoutMs:

{
  cron: {
    runTimeoutMs: 0,  // default 30000ms for backward compat; 0 = no timeout
  }
}

Option C (most explicit): Require users to always pass --timeout for cron run, removing the default entirely.

Workaround (current)

openclaw cron run <id> --timeout 0

A shell alias mitigates it:

alias cronrun="openclaw cron run --timeout 0"

Metadata

  • OpenClaw version: 2026.3.23-2
  • Related: agents.defaults.subagents.runTimeoutSeconds (already supports 0 = no timeout for subagents, but cron run is a separate code path)

extent analysis

Fix Plan

To fix the hardcoded default timeout issue in the openclaw cron run CLI command, we will implement Option B: Add a config flag cron.runTimeoutMs. This approach allows for backward compatibility while providing users with the flexibility to configure the timeout as needed.

Step-by-Step Solution:

  1. Update Configuration Schema: Add cron.runTimeoutMs to the configuration schema with a default value of 30000 for backward compatibility.
  2. Modify CLI Entry Point: Update cron-run.js to read the cron.runTimeoutMs value from the configuration and use it as the default timeout if the --timeout flag is not provided.
  3. Implement Config Flag: Allow users to set cron.runTimeoutMs in their configuration files. If set to 0, the CLI command will wait indefinitely for the job to complete.

Example Code Snippets:

// In cron-run.js, read config and apply default timeout
const config = require('./config');
const defaultTimeout = config.cron.runTimeoutMs || 30000;

// ...

// Use defaultTimeout if --timeout flag is not provided
const timeout = argv.timeout || defaultTimeout;
// Example configuration with custom timeout
{
  "cron": {
    "runTimeoutMs": 90000 // 90 seconds
  }
}

Verification

To verify that the fix worked:

  • Run openclaw cron run <id> without the --timeout flag and ensure it waits for the job to complete based on the configured cron.runTimeoutMs.
  • Test with different values for cron.runTimeoutMs (e.g., 0 for no timeout, a specific value like 90000 for 90 seconds) to confirm the behavior matches the configuration.

Extra Tips

  • Document the new cron.runTimeoutMs config flag and its usage to help users understand how to customize the timeout behavior.
  • Consider adding a warning or deprecation notice for the hardcoded default timeout to encourage users to adopt the new configurable approach.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#container setup#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING