Migrate from EasyCron
Move your EasyCron URL jobs to SteadyCron step by step — recreate each job in a YAML manifest, run both in parallel, then switch off EasyCron.
EasyCron calls your URLs on a schedule. SteadyCron does the same — and adds retries with backoff, per-job timeout enforcement, heartbeat monitoring, alerts on Slack, Discord, Telegram, email, and webhooks, and a YAML/Terraform workflow so your schedules live in git instead of a dashboard.
There is no EasyCron export file to import, so the migration is a short manual loop: recreate each job, run both side by side, then switch off the old one.
1. List your EasyCron jobs
In the EasyCron dashboard, note down for each cron job:
- the URL (and HTTP method, if it’s not a plain GET)
- the cron expression and timezone
- any custom headers or auth the endpoint expects
2. Recreate each job in a manifest
steadycron manifest add job appends one job at a time to steadycron.yaml — it validates
the result and never touches your existing entries:
steadycron manifest add job --kind http --name nightly-report --schedule "0 2 * * *"
Or write the manifest directly:
jobs:
- id: nightly-report
name: Nightly report
kind: http
method: GET
url: https://app.example.com/tasks/nightly-report
schedule: "0 2 * * *"
timezone: Europe/Berlin
retries: 3
headers:
Authorization: Bearer ${CRON_SECRET} # resolved from --env-file at apply time
Then validate and apply:
steadycron validate steadycron.yaml
steadycron apply steadycron.yaml --env-file secrets.env --namespace prod
3. Run both in parallel, then switch off
Let SteadyCron and EasyCron both call the endpoint for a day or two (make sure the task is idempotent, or stagger the two schedules by a few minutes). Check the execution log for green runs, then pause or delete the EasyCron job.
What you gain
| EasyCron | SteadyCron | |
|---|---|---|
| Retries on failure | Limited, plan-dependent | Configurable with exponential backoff |
| Timeout enforcement | Plan-dependent | Per job |
| Heartbeat monitoring for your own crons | No | Yes |
| Alert channels | Email, webhook | Email, Slack, Discord, Telegram, webhook |
| Schedules in git (YAML / Terraform) | No | Yes — validate, plan, apply |
| Hosting | US | EU (GDPR-native, signed DPA) |
Next steps
- YAML & CLI — full manifest workflow
- HTTP jobs — request builder, retries, timeouts
- Alerting — route failures to the right channel