ez-cronjob

Documents the cron failures that actually recur in Clawdbot/Moltbot deployments — messages not delivered, jobs stuck in error status, arrivals at the wrong time from timezone bugs, tool timeouts, and fallback models ignoring instructions — with fixes for each. Because it is written from production debugging rather than documentation, the failure list is the useful artifact; keep it open whenever a schedule misbehaves.

Use case: Diagnosing why a scheduled message lands at the wrong local time

# The four cron failures that account for most production pain This skill is a debugging taxonomy rather than a setup guide, and that is what makes it useful: when a schedule misbehaves, the problem is almost always one of a small, recurring set. ## 1. The message was never delivered The job ran and the output went nowhere, or the send failed silently. Check the job's last status and last error before rewriting the job — a delivery failure that is reported as success is the most expensive kind, because the schedule looks healthy while nothing arrives. ## 2. The job sits in error status A job marked error is a job you can recover, but only if you know why. Read the error text and classify it: transport/connection errors are retryable, while validation and authentication errors are deterministic and will fail identically on every retry. Retrying the second class just multiplies noise. ## 3. Messages arrive at the wrong time Timezone bugs are the classic. A schedule expressed in one zone, evaluated in another, fires reliably at the wrong hour — and the failure is invisible until someone notices the briefing arrived at 3am. Pin the timezone explicitly in the job definition rather than inheriting the host's. ## 4. The agent times out on the tool call, or a fallback model ignores instructions Long jobs exceed the tool timeout, and the fallback path can behave differently from the primary model — sometimes ignoring the instructions embedded in the prompt. If a job only fails on the fallback branch, that is the branch to inspect, not the job. ## Practical loop 1. Read the last status and last error before changing anything. 2. Classify the error: retryable transport or deterministic logic. 3. Check the timezone the schedule is actually evaluated in. 4. Confirm the job is not running twice — a single-flight guard prevents overlap. 5. Change one thing, then observe a full cycle. ## Tips - Always read lastError before editing the job; the text usually names the class. - State the timezone explicitly in every job that human eyes will read. - Only auto-retry transport-class errors, and only once per heartbeat. - Gotcha: a delivery failure can leave the job looking successful, so alert on absence of output as well as on errors. - Gotcha: a fallback model may not honour the prompt as reliably as the primary, so compare behaviour across branches.