Migrate from cron scripts
Replace hand-run scripts and crontab entries with routines that keep the schedule syntax and add traces, limits, and permissions.
This guide moves report-shaped cron jobs — scripts that gather data, summarize it, and post or email a result — into Work on Repeat routines. Jobs that mutate production systems belong in your infrastructure, not here; see Limitations.
Prerequisites
- A Work on Repeat account and an available integration or your own MCP server exposing the data the script reads.
- The crontab entries and scripts you are replacing, plus a sample of their recent output.
Concept mapping
| Cron + script | Work on Repeat |
|---|---|
| Crontab entry | Routine schedule — the same five-field syntax, plus an explicit IANA timezone |
| Script body | Written instructions plus enabled tools |
| Server credentials / env vars | Connections with encrypted, masked credentials |
| Log files | Run traces (every model step and tool call) |
| Timeouts you wrote yourself | Built-in idle and wall-clock limits |
Export and back up
Keep the script in version control and its crontab line commented, not deleted. Capture a few recent outputs as the comparison baseline.
Connections and permissions
Replace embedded credentials with connections: each credential is encrypted, masked after setup, and scoped to one provider endpoint. Enable only the reads the report needs.
Routine setup and schedule translation
The schedule copies verbatim — 0 7 * * 1-5 is valid here too — but you add
a timezone, so a job that drifted an hour every DST change stops drifting.
Rewrite the script's intent as instructions: what to gather, how to
summarize, where to deliver, and what to do when a source is empty. Signed
result webhooks can feed whatever consumed
the script's output.
Validate, cut over, roll back
Run manually and compare against the baseline outputs. After a clean cycle, comment out the crontab entry. Rollback is uncommenting it.
Limitations
- The model reads through tools; a script that shells into private systems needs an MCP server in front of that data first.
- Runs are time-bounded by design — long batch jobs are not a fit.
- Byte-identical output is not the goal; validate that decisions the report drives stay the same.