Bug: Cron job actual timeout is 1/3 of configured timeoutSeconds #29774
Description
Problem
Cron jobs with payload.timeoutSeconds set are timing out at exactly 1/3 of the configured value.
Evidence
| Job | Agent | Model | Configured timeoutSeconds | Actual Duration at Timeout |
|---|---|---|---|---|
| circe-soul-evolution | circe | litellm/claude-opus-4-6 | 900s | 300s (1/3) |
| atlas-discord-audit | atlas | litellm/claude-sonnet-4-6 | 180s | 60s (1/3) |
Both jobs fail with Error: cron: job execution timed out at exactly 1/3 of their configured timeout.
Expected Behavior
Jobs should timeout at the configured timeoutSeconds value (900s and 180s respectively).
Actual Behavior
Jobs timeout at exactly timeoutSeconds / 3 (300s and 60s respectively).
Environment
- OpenClaw: 2026.2.26
- macOS 26.3 (arm64)
- Node: v22.22.0
agents.defaults.timeoutSeconds: not set (default 600)
Source Analysis
Reviewed the timeout resolution chain:
resolveCronJobTimeoutMs()ingateway-clicorrectly readspayload.timeoutSecondsresolveAgentTimeoutMs()inreplycorrectly receivesoverrideSecondsfrompayload.timeoutSeconds- Both functions appear to produce the correct ms value
The 1/3 ratio is consistent across different jobs, agents, and models, suggesting a systematic issue rather than coincidence. Possibly a triple-layer timeout where the shortest wins, or a unit conversion issue somewhere in the execution pipeline.
Reproduction
Set a cron job with timeoutSeconds: 900 and a prompt that takes >300s to complete. The job will fail at ~300s instead of 900s.