Ecman

EasyCron

EasyCron web cron jobs as code in a Ruby DSL

Manages
EasyCron scheduled jobs
Language
Ruby
Package
ecman
CLI
ecman
Config file
ecman.rb
The codenize-tools/ecman repository is archived on GitHub and has been dormant since 2016; EasyCron's API has evolved since the tool was written.
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
In short

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.

Key facts
  • Manages EasyCron hosted cron jobs from a Ruby DSL file.
  • Each job is a cron_job block: expression, URL, email, and log length.
  • A dry-run previews every change, and applies are idempotent.
  • Uses a single EASYCRON_TOKEN for 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.
Illustration: EasyCron scheduled jobs managed as code with Ecman
Getting started

Install and run Ecman

1

Install

Install the ecman gem (Ruby required).

$ gem install ecman
2

Export current state

Pull the live EasyCron configuration into a ecman.rb.

$ ecman export ecman.rb
3

Dry-run, then apply

Preview the diff, then apply the change for real.

$ ecman apply ecman.rb --dry-run

Ecman 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.

Pro tip

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.

Capabilities

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.

In practice

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.

FAQ

Ecman questions, answered

Is Ecman still maintained?
No. The ecman repository is archived on GitHub and dormant since 2016. EasyCron itself still operates and its API has changed since then, so test carefully against a disposable account before trusting it with a production schedule.
What happens to jobs not in the DSL?
Ecman is declarative. Jobs in the EasyCron account but missing from the file are removed on apply so the account matches the file. Run ecman apply ecman.rb --dry-run first and read the plan, especially on shared accounts.
How does Ecman authenticate with EasyCron?
With your EasyCron API token, set via the EASYCRON_TOKEN variable or the --token option. Anyone with the token can rewrite the schedule, so store it as a CI secret, not in the repo.
What job settings can the DSL express?
The documented DSL covers the job name, its cron_expression, the url to request, the email_me setting, and log_output_length. Newer EasyCron features fall outside what the archived tool models.
What should I use instead today?
If you run your own servers, a scheduler like Cronicle gives you jobs as JSON with a REST API and active maintenance. To stay on hosted cron, EasyCron's REST API can be driven from scripts or CI directly, using Ecman's export-review-apply loop as the model.