Cronicle
CronicleA multi-server task scheduler with scheduled jobs as configuration
- Manages
- Cronicle job scheduler
- Language
- Node.js
- CLI
- control.sh
- Config file
- config.json
{
"title": "DB Reindex",
"enabled": 1,
"category": "43f8c57e",
"plugin": "test",
"target": "db1.int.myserver.com",
"timezone": "America/New_York",
"timing": {
"hours": [ 21 ],
"minutes": [ 20, 40 ]
},
"retries": 0,
"retry_delay": 30,
"timeout": 3600,
"notes": "This event handles database maintenance.",
"web_hook": "http://myserver.com/notify-chronos.php"
}Cronicle is a multi-server task scheduler and job runner built on Node.js, with a web UI and a JSON REST API. It replaces scattered crontabs with one central schedule that has history, retries, and failover. Because every event is JSON, you can keep the schedule in Git and push it from CI.
What is Cronicle?
Cronicle is a multi-server task scheduler and job runner with a web UI. It is built on Node.js, not Ruby. It handles scheduled, repeating, and on-demand jobs across many worker servers, with live stats and a log viewer. Unlike the Ruby gems in the codenize-tools family, Cronicle is a full server you install and run.
It earned its place in the directory as the toolbox's job runner. Every part of it is JSON you can manage as configuration. The problem it solves is crontab sprawl: jobs scattered across servers, no history, no failover, and no record of who changed what. Cronicle centralizes the schedule. Its JSON REST API lets you create, export, and update events from scripts, so the schedule can live in version control and ship from CI, in the spirit of codenization.
It fits teams that outgrew plain cron but do not want a heavy workflow engine. One install gives scheduling, a UI for operators, and an API for automation.
- A Node.js multi-server job scheduler with a web UI, not a Ruby gem.
- Every job is a JSON event you can export, diff, and commit.
- Managed through a JSON REST API with per-key privileges.
- Has no dry-run; the Git diff and a staging instance are your safety net.
- For hosted cron managed the same way, see Ecman.
- Actively maintained, with xyOps named as its successor.
Install and run Cronicle
Install
Install via your package manager.
$ curl -s https://raw.githubusercontent.com/jhuckaby/Cronicle/master/bin/install.js | nodeExport current state
Pull the live Cronicle configuration into a config.json.
$ curl "http://localhost:3012/api/app/get_schedule/v1?api_key=YOUR_API_KEY"Dry-run, then apply
Preview the diff, then apply the change for real.
$ curl -X POST -H "Content-Type: application/json" -d @event.json "http://localhost:3012/api/app/create_event/v1"Cronicle has no Ruby DSL and no built-in dry-run. Even so, the same export, review, apply loop maps onto its JSON REST API. Export the full schedule with the get_schedule endpoint (authenticated by an API key) and commit the JSON to Git. Each event, its title, plugin, target, timing, retries, and limits, is a plain JSON document that diffs cleanly in a pull request.
To change a job, edit the JSON and push it back with create_event or update_event. The API key needs the matching create_events or edit_events privilege. Because there is no dry-run, the review step carries the weight. The Git diff is your change plan, and a staging Cronicle instance is the safest place to test it first. Server settings live in config.json, which you can version-control directly.
There is no dry-run, so stage risky jobs with enabled: 0. The event exists and can be reviewed, but it will not fire until you flip it on.
What Cronicle can do
Multi-server scheduling with failover
Jobs can target server groups or single hostnames. Failover to backup servers is automatic, and new servers can be auto-discovered as the cluster grows.
Web UI with live logs
A built-in front end shows real-time job status, a live log viewer, and CPU and memory graphs. Operators do not need shell access to see what ran.
JSON REST API with API keys
Endpoints like <code>get_schedule</code>, <code>create_event</code>, and <code>update_event</code> speak plain JSON. API keys with granular privileges are the hook that makes schedules manageable as code.
Plugins in any language
Jobs run through plugins, which are just executables that read JSON from stdin. Write them in shell, Python, Node.js, or anything on the worker.
Job control primitives
Events support retries with delay, timeouts, concurrency limits, job queuing, catch-up runs for missed schedules, and per-event timezones.
Resource limits and webhooks
Per-job CPU and memory limits stop runaway tasks. Webhooks plus success and failure alerts tie job outcomes into chat and alerting.
| Plain crontab | Cronicle |
|---|---|
| Edited on each server | One central schedule for the whole cluster |
| No run history | Full history, live logs, and stats |
| No retries or timeouts | Built-in retries, timeouts, and queuing |
| Silent if a server dies | Automatic failover to backup workers |
| Hard to review | JSON events you can diff in Git |
When teams reach for Cronicle
Replacing scattered crontabs
Move per-server cron entries into one Cronicle cluster. Jobs gain history, retries, timeouts, and a UI. The schedule stops being undocumented <code>crontab -l</code> output across machines.
Schedules managed from CI
Keep event definitions as JSON files in a repo and apply them through the REST API on merge. New jobs and timing changes get review, and the API key's privileges limit what CI can touch.
Batch jobs on worker pools
Target a server group so nightly ETL or reindex jobs run on whichever worker is free. Failover covers a downed primary, and CPU and memory limits protect co-tenant work.
On-demand jobs behind an API
Define an event with no timing and it becomes on-demand only. Users run it in the UI, or remote apps call <code>run_event</code>. It is a light way to expose operational scripts safely.