# Cronicle: a multi-server cron replacement with a web UI > Cronicle is a Node.js task scheduler that spreads jobs across worker servers and shows live logs in a browser. It is aimed at teams that have outgrown crontab, and the README now points new users at xyOps instead. **jhuckaby/Cronicle** — A simple, distributed task scheduler and runner with a web based UI. - Repository: https://github.com/jhuckaby/Cronicle - Website: http://cronicle.net - Stars: 5,847 · Forks: 509 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/jhuckaby-cronicle ## What Cronicle replaces, and for whom Crontab runs on one machine. It has no notion of a job that can run on any of five servers, no retry record, no live output, and no way to trigger a run from an external system without shelling into the box. Cronicle is built for that gap. The README describes it as "a multi-server task scheduler and runner, with a web based front-end UI" that handles "scheduled, repeating and on-demand jobs, targeting any number of worker servers, with real-time stats and live log viewer." The intended user is an operations or platform engineer who already has a handful of Linux servers and wants a single place to define jobs, watch them run and see history. Because plugins are described as "any executable script in any language" that reads and writes JSON, the tool does not force a language choice on the jobs themselves. The scheduler is Node.js, the jobs are whatever you can execute. One caveat shapes everything below. The README opens with an announcement for xyOps, called "the spiritual successor to Cronicle," and states that "Cronicle will still be supported and maintained going forward (mainly bug fixes and security issues will be patched)." That is a maintenance commitment, not a feature roadmap. The last push to the repository was on 2026-09-16, and releases v0.9.132, v0.9.133 and v0.9.134 landed on 2026-09-08, 2026-09-11 and 2026-09-16 respectively, so the project is still receiving changes. Read the announcement before you plan a migration onto it. ## How the primary, backup and worker servers fit together Cronicle is not a single daemon. The glossary in the README defines four roles. The primary server "keeps time and runs the scheduler, assigning jobs to other servers, and/or itself." A backup server is "a worker server which will automatically become primary and take over duties if the current primary dies," which is the failover story. A worker server "sits idle until it is assigned jobs by the primary server." Server groups are named sets of servers that events can target, and they can be tagged "primary eligible" or "worker only." That gives a data flow you can reason about. The primary holds the schedule, decides when an event is due, picks a target from the event's server or group, and dispatches the job. Workers execute and report back. The UI subscribes over socket.io, which is why the log viewer is live rather than a poll. Each job is an instance of an event, and the README's own example is that an event set to run hourly creates a new job every hour. The vocabulary matters when you are reading the docs, because the terms are not interchangeable. An event is a schedule entry that points at a plugin and a target. A job is one execution of that event. A plugin is the executable. A category groups events and can set defaults and a colour in the UI. If you skim the configuration file without that mapping, the keys look arbitrary. The design has a real cost: the primary is a coordination point for dispatch. The README promises automated failover to backup servers, but it does not describe the failover window, whether an in-flight job is retried on the new primary, or how a split brain between two primaries is prevented. Those are the questions to take to docs/InnerWorkings.md, which the README links but does not summarise. ## Installing Cronicle and scheduling a first event The README does not carry install steps. It links to a separate document, docs/Setup.md, for "Installation & Setup," and package.json gives the shape of the install. The engines field requires Node.js 22.12.0 or later, and the package declares a postinstall script that runs pixl-boot install, so the boot step is part of npm install rather than something you run afterwards. A minimal install from a source checkout therefore looks like this. The exact commands come from package.json, not from the README, which is silent on the details. ```bash npm install npm run boot ``` The postinstall hook fires during npm install, and npm run boot maps to the same pixl-boot install command, so running it twice is harmless. The bin field points at bin/control.sh, which is the control script for the daemon; the repository also has a bin/ directory alongside lib/, htdocs/ and sample_conf/. The sample_conf/ directory is where you should look for a starting configuration, and docs/Configuration.md is the document the README names for it. Once the service is up, the workflow is: create an event in the web UI, point it at a plugin, choose a server or server group, and set a schedule. For a first run, use an on-demand event rather than a timed one so you get immediate feedback in the live log viewer. The REST API and API keys exist for the case where you want an external system to trigger that event instead of a human clicking a button; docs/APIReference.md is the reference the README points to. If you would rather not run it directly on the host, note that the README and the linked document list do not cover Docker or Kubernetes. Neither term appears in the README or in the linked document titles, so there is no official image documented there and any container setup is something you assemble yourself from the Node.js requirement and the boot script. ## Where Cronicle is the wrong tool Cronicle assumes long-lived servers that it can discover and dispatch to. If your workloads run on ephemeral containers that appear and disappear, the worker model fights you: a worker that "sits idle until it is assigned jobs" needs to be reachable and registered, and the auto-discovery feature is described as finding "nearby servers," which implies a stable network neighbourhood rather than a scheduler that scales pods up and down. The second limit is the maintenance posture. The README's own words are that Cronicle will get "mainly bug fixes and security issues." If your evaluation criteria include new features, active design work or a roadmap, this is not the project for that, and the README says so at the top of the page rather than burying it. The last push was on 2026-09-16 and the most recent release is v0.9.134, so the project is not abandoned, but the stated intent is maintenance. The third is scope. Cronicle schedules and runs commands and plugins. It is not a workflow engine with dependencies between steps, and the README does not claim to be one. If your jobs form a directed graph where step three needs the output of step two, you will be encoding that in a plugin or a shell script rather than expressing it in the scheduler. Finally, the repository's licence metadata is inconsistent. The repository is labelled NOASSERTION, while package.json declares "license": "MIT" and the tree contains LICENSE.md. That is a discrepancy to resolve with whoever handles licensing at your organisation, not something to assume either way. ## Cronicle against plain cron and against a queue-based runner The honest comparison is with cron itself, because that is what Cronicle says it is: "basically a fancy Cron replacement written in Node.js." Cron is a single-host scheduler with no state beyond the crontab file. Cronicle adds a database-backed schedule, a web UI, live logs, per-job CPU and memory tracking, historical graphs, webhooks and a REST API. The trade is operational surface: cron needs nothing running, Cronicle needs a Node.js service, a primary election between servers and a storage backend. For one server with three jobs, cron wins on simplicity, and no amount of UI changes that. The other comparison worth drawing is against a job queue such as a message-broker-backed worker pool. A queue is built around throughput and horizontal scale: producers push work, consumers pull it, and the broker handles back-pressure. Cronicle is built around time and targeting: the primary decides that an event is due and chooses a server group to run it on. If your problem is "run this at 02:00 in the Europe/London timezone," Cronicle models it directly and a queue does not. If your problem is "process ten thousand messages an hour," a queue models it and Cronicle does not, since it assigns jobs rather than streaming work. The README notes that long-running events can optionally be queued, which is a scheduling nicety, not a throughput mechanism. ## Licence, dependencies and the cost of upgrading package.json declares MIT, and the repository root carries LICENSE.md. The repository metadata says NOASSERTION, which typically means an automated classifier could not match the file to a known licence. The README's colophon lists the third-party modules Cronicle is built on, with their licences: async, chart.js, jquery, moment, socket.io and most of the rest under MIT, bcryptjs and uglify-js under BSD variants, and font-awesome and mdi under OFL-1.1 and MIT. That list is a starting point for a dependency review, not a substitute for one, and it does not cover transitive dependencies. Upgrade cost is where a scheduler earns or loses its keep, and the README does not document a rollback procedure. The repository has a CHANGELOG.md at the root and a changelog script (node bin/changelog.js) that generates it, so release notes are the place to check before upgrading. The release cadence visible in the repository is roughly one release every few days in September 2026, which means pinning to a version is more practical than tracking every tag. The dependency pinning is worth noting. package.json carries an overrides block fixing nanoid at 3.3.18, picomatch at 4.0.4 and ws at 8.21.0, and several direct dependencies are pinned to exact versions rather than ranges, including moment at 2.29.4 and socket.io at 4.8.3. That makes builds reproducible but means security updates to those packages arrive only when a new Cronicle release ships them, which is a real consideration given the stated maintenance mode. ## Conclusion Adopt Cronicle if you already run it, need a self-hosted scheduler with a browser UI and want a documented REST API and plugin contract. Do not adopt it for a greenfield project: the README names xyOps as the successor and states that Cronicle will receive mainly bug fixes and security patches. Before committing, read docs/Setup.md, confirm your Node.js version satisfies the engines field of package.json, and decide whether the MIT licence in package.json settles the NOASSERTION label on the repository. ## FAQ ### What is the Cronicle scheduler? Cronicle is a multi-server task scheduler and runner with a web based UI, written in Node.js. It handles scheduled, repeating and on-demand jobs across any number of worker servers, with real-time stats and a live log viewer. ### How do I install Cronicle? The README does not contain install steps; it links to docs/Setup.md for installation and setup. From a source checkout, package.json requires Node.js 22.12.0 or later and runs pixl-boot install as a postinstall step. ### What languages can Cronicle plugins be written in? The README states that plugins can be written in virtually any language, because a plugin is any executable script that reads and writes JSON to communicate with Cronicle. The plugin documentation is in docs/Plugins.md. ### Does Cronicle have a REST API? Yes. The README lists a simple REST API for scheduling and running events, plus API keys for authenticating remote apps so they can trigger jobs. The API reference is in docs/APIReference.md. ### Is Cronicle still maintained? The README states that Cronicle will still be supported going forward, mainly with bug fixes and security patches, and that xyOps is its spiritual successor. The last push to the repository was on 2026-09-16. ## Sources - [Issues](https://github.com/jhuckaby/Cronicle/issues) - [jhuckaby/Cronicle on GitHub](https://github.com/jhuckaby/Cronicle) - [Project website](http://cronicle.net) - [README](https://github.com/jhuckaby/Cronicle/blob/master/README.md) - [Releases](https://github.com/jhuckaby/Cronicle/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jhuckaby-cronicle