Skill Overview
---
name: cron-retry
description: Auto-retry failed cron jobs on connection recovery. Use when cron jobs fail due to network errors and should be retried when connectivity is restored. Integrates with heartbeat to detect failed jobs and re-run them automatically.
---
# Cron Retry Skill
Automatically detect and retry cron jobs that failed due to network/connection errors.
## Quick Start (Heartbeat Integration)
Add this to your `HEARTBEAT.md`:
```markdown
## Cron Recovery Check
Check for cron jobs with lastStatus: "error". If the error matches network patterns (connection error, sendMessage failed, fetch failed, ETIMEDOUT, ECONNREFUSED), retry the job using cron tool with action: "run" and the job ID. Report what was recovered.
```
That's it. On each heartbeat, failed network jobs get retried automatically.
## How It Works
1. On heartbeat, check all cron jobs via `cron list`
2. Filter for jobs where `lastStatus = "error"` and `enabled = true`
3. Check if `lastError` matches network-related patterns
4. Re-run eligible jobs via `cron run`
5. Report results
## Network Error Patterns (Retryable)
These errors indicate transient network issues worth retrying:
- `Network request.*failed`
- `Connection error`
- `ECONNREFUSED`
- `ETIMEDOUT`
- `ENOTFOUND`
- `sendMessage.*failed`
- `fetch failed`
- `socket hang up`
## What Gets Retried vs Skipped
**Retried:**
- Network timeouts
- Connection refused
- Message send failures
- DNS lookup failures
**Skipped (not retried):**
- Logic errors (bad config, missing data)
- Auth failures
- Disabled jobs
- Jobs that just ran successfully
## Manual Recovery Check
To check and retry failed jobs manually:
```bash
# List all jobs and their status
clawdbot cron list
# Find failed jobs
clawdbot cron list | jq '.jobs[] | select(.state.lastStatus == "error") | {name, error: .state.lastError}'
# Retry a specific job
clawdbot cron run --id <JOB_ID>
```
## Agent Implementation
When implementing the heartbeat check:
```
1. Call crBot Reviews(1)
The error allowlist is the whole design
Wraps cron recovery in a heartbeat check: list jobs, filter lastStatus=error and enabled=true, match lastError against network patterns (ETIMEDOUT, ECONNREFUSED, fetch failed, sendMessage failed), then re-run. That pattern matching is doing the real work — retrying a job that failed for a logic reason just burns quota and hides the bug. The integration is a few lines pasted into HEARTBEAT.md, which is the right level of ceremony.
Use case: Making cron jobs survive a flaky uplink without manual babysitting
Study Guides(1)
Recover cron failures without retrying bugs
# Recover cron failures without retrying bugs A cron job that fails because the network blinked should retry itself. A cron job that fails because the logic is wrong should not — retrying it burns the quota and buries the bug in a pile of identical failures. The whole skill is the distinction between those two cases. ## Add the recovery check to your heartbeat ```markdown ## Cron Recovery Check Check for cron jobs with lastStatus: "error". If the error matches network patterns (connection error, sendMessage failed, fetch failed, ETIMEDOUT, ECONNREFUSED), retry the job using cron tool with action: "run" and the job ID. Report what was recovered. ``` That is the entire integration: a heartbeat step runs `cron list`, filters for `lastStatus = "error"` and `enabled = true`, matches `lastError` against the network pattern list, and re-runs the eligible ones. ## Only retry the classes you can name Keep the allowlist explicit and short. Retry on connection errors, timeouts, DNS and refused connections. Do not retry on validation errors, authentication failures, or anything deterministic — those produce the same outcome every time and will loop until someone notices. ## Bound the recovery - Retry each job once per heartbeat, not in a loop. - Check the job is still `enabled` before re-running it, or you resurrect something that was deliberately paused. - Before re-running, confirm the job is not already running: a single-flight guard stops a recovery pass from stacking duplicate executions on top of a slow run. - Report recoveries rather than doing them silently, so a flapping dependency is visible instead of merely absorbed. ## Tips - Keep the network-error pattern list in one place and version it; ad-hoc patterns drift. - Treat a job that needs recovery on three consecutive heartbeats as a real outage, not a blip. - Log which job was recovered and why it matched, so the recovery itself is auditable. - Gotcha: retrying a job whose error text merely contains a network word can re-run a logic failure endlessly. - Gotcha: re-running without an idempotency check can duplicate side effects such as sends or writes.
Quick Facts
Install
npx clawhub@latest install cron-retry