Ancient rites of scheduling, made easy.

Cronomicon schedules and runs your Bash, Ansible, Terraform, PowerShell, Perl and Python jobs from one web console, across every host, department and network zone. It ships as one Go binary with one SQLite file, and it’s open source.

Get Cronomicon Take the tour
v2.0.1Latest release notes
The Cronomicon emblem: a hooded figure reading a glowing book, framed by gears and an infinity loop

Score

last 24 hours and next 12, in time-lapse
The Dashboard’s timeline, running nine sample jobs at 600× speed. Hover a mark to inspect it.
Runs what your team already writes:
  • bash
  • ansible
  • terraform
  • powershell
  • perl
  • python

Every job, every run, one console

Cronomicon replaces the crontabs scattered across your servers with a single place to see what runs, when, where, and how it went. Here’s the real app, in both themes.

Start on the Dashboard, open a job in the catalog and run it: the Run dialog shows the targets, then asks you to confirm. Flip to light mode, open a run in History, and finish on a workflow’s steps.

Build jobs from parts you already have

Scripts, schedules and variables are separate, reusable pieces. Put them together into a job, then chain jobs into a workflow. Change a schedule once and every job that uses it follows.

  1. Register a script

    A playbook, a .tf directory or a shell script. Cronomicon scans it for the environment variables it reads, so you know what to define before the first run.

    backup-db.shpatch.ymlplan.tf

  2. Bind it to a scope and a schedule

    A scope is the set of hosts a job may touch. A schedule is a cron expression with an optional activation window. Both are reusable.

    Production0 2 * * *business-hours

  3. Attach variables and secrets by reference

    A job names the variables it needs and never holds their values. Values are resolved when the job is dispatched, from Cronomicon’s encrypted store or from HashiCorp Vault.

    DB_HOSTvault:db/backup

  4. Run it, or chain it

    The job is live. Add it to a workflow with other jobs, with branches, parallel groups and values passed from one step to the next.

    nightly-db-backup
jobs/nightly-db-backup.yamlGit git
apiVersion: cronomicon.io/v1
kind: Job
metadata:
  name: nightly-db-backup
spec:
  script_ref: backup-db.sh
  scope: Production        # where it runs
  schedules:
    - name: nightly
      cron: "0 2 * * *"     # when it runs
  timeout_seconds: 3600
  retries: 2
Keep it in Git gitDefinitions sync from a GitLab repository on push. Validate them in CI with cronomicon validate, and review changes like any other code.
Or compose it in the app cronomiconBuild jobs, workflows and schedules in the browser and they go live immediately. Every edit keeps a revision you can restore.

Six ways to start a run, one set of rules

Cron is only the beginning. Every source that can start a run passes through the same gates, so a paused job stays paused however it’s triggered.

  • A schedule

    Cron with activation windows, intervals and one-off runs.

    0 */4 * * *

  • A click

    Run now or later from the Run dialog, with per-run overrides.

    Run now

  • A Git push

    A GitLab webhook syncs definitions the moment they merge.

    git push

  • An API token

    Service accounts trigger runs from CI or other tools.

    POST /trigger/…

  • Another run finishing

    Reactions fire when a job or workflow succeeds, fails or is stopped.

    when a run fails

  • A file arriving

    Runners watch drop directories, including NFS and CIFS shares.

    /drop/*.csv

Chain jobs into workflows

Put jobs in order, branch on the result, and run steps in parallel. Each step can pass its output to the next. Draw a workflow on a graph canvas or write it in YAML.

prod-release5 steps, started by hand Last run: success in 6m 41s
Workflow graph: terraform-plan-prod runs first. On success, terraform-apply-prod runs with the VERSION output from the plan, then smoke-test and disk-usage-audit run in parallel. On failure, notify-oncall runs instead. On success On failure Parallel group terraform-plan-prod Terraform, emits VERSION terraform-apply-prod Terraform, reads VERSION=1.4.2 notify-oncall Bash, only if the plan fails smoke-test Python, 2 retries disk-usage-audit Bash, every host in scope cache-warm another workflow Reaction when this succeeds

Swipe sideways to see the whole workflow.

  • Branch on the resultSend a failed plan to the on-call path instead of apply. Branches can nest.
  • Run steps in parallelGroup jobs to run side by side. Each step has its own retries, inputs and soft-cancel behaviour.
  • Pass values between stepsA step prints ::cronomicon-output name=VERSION::1.4.2 and the next step reads VERSION as an environment variable.
  • Nest and reactA workflow can call another workflow, up to three levels deep. Reactions start new runs when one finishes, with a hard depth limit so they can’t loop.

Runners dial out. Nothing dials in.

Reach ordinary hosts over SSH, directly or through a bastion. For isolated networks, install a runner agent inside the zone. It polls Cronomicon for work over HTTPS, so the zone needs no inbound firewall rules.

Topology diagram. Operators sign in to the Cronomicon server through single sign-on. The server reaches hosts db-01, web-01 and lb-01 over SSH through a bastion. Runner agents in three isolated zones, agency-alpha, agency-beta and the general pool, poll the server over outbound HTTPS. The server also connects to GitLab, Vault and S3. Operators browser or API Sign in with SSO Cronomicon API, scheduler and UI one binary + cronomicon.db SSH bastion ProxyJump db-01 web-01 lb-01 Hosts in scope agency-alpha linux-01ansible, vault linux-02bash, ansible agency-beta report-01perl, python linux-03terraform General pool win-01powershell linux-04bash Outbound HTTPS GitLab Vault S3 Definitions, secrets, log archive and backups

Swipe sideways to see the whole topology.

Isolation is set by operators. Each scope belongs to an agency, which is a department or network zone. A job is only handed to a runner in the same agency. Runners can’t choose their own agency.

Work goes where it can run. Runners advertise what they can do, such as Ansible collections, Vault access or Terraform. A job waits for a runner that meets its requirements, and you can pin a run to a tagged runner.

Checkouts are opt-in. Running full Ansible projects requires an allowlisted repository, a commit pinned by the server, a read-only deploy key, and a secret scan of the checked-out tree.

Built for the departments that share it

Several teams can share one Cronomicon. Each team sees and runs only its own jobs, secrets never reach a log, and every change is recorded.

nightly-db-backupRun log in History
02:00:04 Connecting to db-01 as svc_backup
02:00:04 Authenticating with token [REDACTED]
02:00:05 pg_dump app_db > /backups/app_db.sql
02:02:11 Uploading with key [REDACTED]
02:02:17 Done, exit 0
ActivitySearchable, kept as long as you choose
  1. alice@corp.example changed the schedule of nightly-db-backup
  2. bob@corp.example drained runner linux-03
  3. Git sync updated 3 definitions
  4. svc-deploy triggered prod-release with an API token
Access by department
AD groups map to roles and agencies through access grants, with seven permissions. Team leads can manage access for their own agencies without full admin rights.
Secrets by reference
Stored secrets are encrypted with AES-256-GCM, or read from HashiCorp Vault at dispatch. Become-passwords are never passed as environment variables.
Masked everywhere
Secret values, SSH credentials and per-run overrides are replaced with [REDACTED] in run logs and the audit stream before anything is written.
A complete record
Runs, config changes, pushes and syncs land in one Activity feed. Retention is set per data type, and logs can be archived to S3.
Calendars and SLAs
Working calendars skip holidays and change freezes. SLA deadlines flag late runs, and missed-run detection catches schedules that never fired.
Undo built in
Every definition keeps a revision history. Deleted jobs go to a recycle bin until an admin restores or purges them.

One binary. One database file.

The API, scheduler and web UI are one Go process backed by a single SQLite file, with no message broker or separate database server. Run it as a container behind your reverse proxy and identity provider.

Build and run
$ git clone https://github.com/ResetSmith/cronomicon.git
$ cd cronomicon
$ docker build -f backend/Dockerfile -t cronomicon:latest .
$ docker run -d -p 8080:8080 \
    -v /var/lib/cronomicon:/var/lib/cronomicon \
    --env-file cronomicon.env cronomicon:latest
Add a runnertoken from Runners, single use
$ curl -fsSL https://cronomicon.example.com/install/crn_reg_… | sudo bash
Runtime
One static Go binary, UI embedded
State
SQLite, /var/lib/cronomicon/cronomicon.db
Sign-in
OIDC or trusted-header SSO
Execution
Built-in SSH, plus runner agents on Linux and Windows
Metrics
Prometheus at /metrics
Backups
Snapshots to S3 with VACUUM INTO
License
Apache-2.0

Retire the crontabs.

The source, the administrator and user manuals, and a runner install guide are all in the repository. Cronomicon is free to run, change and share under the Apache-2.0 license.

View on GitHub Read the changelog
/etc/crontab on db-01
SHELL=/bin/bash
MAILTO=""
0 2 * * *     root  /opt/scripts/backup-db.sh
*/30 * * * *  root  /opt/scripts/disk-usage.sh
0 4 * * 1     root  certbot renew --quiet
0 0 * * *     root  /usr/sbin/logrotate /etc/logrotate.conf
15 7 * * 1-5  ops   perl /home/ops/report.pl  # ask Dave