Ecman
EasyCronEasyCron web cron jobs as code in a Ruby DSL
- Manages
- EasyCron scheduled jobs
- Language
- Ruby
- Package
- ecman
- CLI
- ecman
- Config file
- ecman.rb
cron_job "example.com" do
cron_expression "0 0 * * *"
url "http://example.com"
email_me 0
log_output_length 0
end
cron_job "www.example.com" do
cron_expression "0 0 * * *"
url "http://www.example.com"
email_me 0
log_output_length 0
end
Ecman is a small Ruby command-line tool that manages EasyCron scheduled jobs as code. You export existing hosted cron jobs into a Ruby DSL file, review edits in Git, then apply them idempotently. A dry-run shows exactly which jobs it would add, change, or remove.
What is Ecman?
Ecman means "EasyCron as Code." It is a small command-line tool that manages jobs on EasyCron, the hosted service that fires HTTP requests on a schedule. Each job declares its cron expression, target URL, email setting, and log length as a cron_job block in a Ruby DSL. Ecman then reconciles the account to match. Auth is a single EASYCRON_TOKEN variable.
Hosted cron services collect the same clutter as server crontabs, with less visibility. Jobs get made through a web form, with no history and no review. Ecman brings the export, review, apply loop to that problem. Schedule changes become diffs in version control, and a dry-run shows exactly what would change before anything does.
It is one of the smallest members of the codenize-tools family, which makes it a good first read for the pattern. For a self-hosted scheduler managed the same way, see Cronicle.
- Manages EasyCron hosted cron jobs from a Ruby DSL file.
- Each job is a
cron_jobblock: expression, URL, email, and log length. - A dry-run previews every change, and applies are idempotent.
- Uses a single
EASYCRON_TOKENfor authentication, ideal for CI. - One of the smallest codenize tools, a good first read for the pattern.
- The repository is archived and dormant since 2016; EasyCron's API has moved on.
Install and run Ecman
Install
Install the ecman gem (Ruby required).
$ gem install ecmanExport current state
Pull the live EasyCron configuration into a ecman.rb.
$ ecman export ecman.rbDry-run, then apply
Preview the diff, then apply the change for real.
$ ecman apply ecman.rb --dry-runEcman follows the export, review, apply loop in its purest form. With EASYCRON_TOKEN set, ecman export pulls every scheduled job from the account into a Ruby DSL file. Commit it, and the current schedule becomes something the team can read. It is often the first complete inventory of what hits which URL and when.
To change the schedule, edit the file and run ecman apply --dry-run. The dry-run compares the file to EasyCron and lists what would be created, updated, or removed, with no side effects. After review, ecman apply makes the change. Because the apply is idempotent, it is safe on every merge. Re-running an unchanged file is a no-op that doubles as a drift check.
Point Ecman at a throwaway EasyCron account first. The tool is old, so confirm its API calls still behave before you let it manage real production schedules.
What Ecman can do
Cron jobs as declarative blocks
Each <code>cron_job</code> block names a job and sets its <code>cron_expression</code>, target <code>url</code>, <code>email_me</code> notification level, and <code>log_output_length</code>. That is the whole EasyCron job in five readable lines.
Export the existing account
<code>ecman export</code> writes every job already in EasyCron into the DSL. You get a committed baseline without recreating anything by hand.
Idempotent apply with dry-run
<code>ecman apply --dry-run</code> prints the planned creates, updates, and deletes without touching the account. The apply itself converges state and does nothing on a second run.
Target filtering
The <code>--target</code> option narrows an export or apply to matching jobs. It helps when one account hosts schedules for several applications.
Simple token authentication
Credentials come from the <code>EASYCRON_TOKEN</code> variable or the <code>--token</code> flag. CI can apply the schedule with a scoped secret and no interactive setup.
When teams reach for Ecman
Webhook schedules in the app repo
Apps that use EasyCron to hit maintenance or report endpoints can keep the DSL file next to the code. Changing a schedule and changing the endpoint happen in one reviewed pull request.
Recovering an undocumented account
One export turns years of web-form jobs into a readable file. From there, dead URLs and duplicate schedules are easy to spot and remove with dry-run-checked diffs.
Consistent schedules across environments
Keep one DSL file per environment, or use <code>--target</code> to scope applies. Staging and production cron jobs then stay in sync instead of drifting apart.