Cronomicon

In Automate Schedule you edit a job on the server and the change is live. In Cronomicon, most job definitions live in a Git repository — version-controlled, reviewed, and synced into Cronomicon.

This is the single biggest change, and it explains most of the times you will find a field you cannot edit. A job that came from Git is read-only in the app, on purpose: the repository is the source of truth, and letting the app overwrite it would mean two answers to "what does this job do".

Cronomicon can also hold jobs of its own, authored in the app. The two kinds live in separate namespaces and never collide — that is the "source" column you will see everywhere, reading either git or cronomicon.

An Automate Schedule job carries everything on one record: the command, the agent, the schedule, the parameters. Cronomicon splits those into four objects that snap together:

• Script — what runs (Bash, PowerShell, Python, Perl, Ansible, Terraform)
• Scope — where it is allowed to run
• Schedule — when it runs
• Env Vars — what it needs to know

A Job is those four bound together. The payoff is reuse: one "nightly at 02:00" schedule serves forty jobs, and fixing it once fixes all forty. The cost is that creating a job feels like assembly rather than filling in a form.

Cronomicon connects over SSH from the server. No agent to install on each target, no per-machine licence, and no "Unlicensed Agents" count to watch.

Runner agents do exist, but for different reasons than you are used to: reaching networks the server cannot reach, and watching directories for files. If your work does not involve either, you may never see one.

Read this one twice. It is the same word doing a narrower job, which makes it the easiest thing on this page to get wrong.

An Automate Schedule calendar can define when a job runs. An Cronomicon working calendar can only suppress a run that a schedule was already going to make. It is a veto, applied just before a scheduled fire. It can never trigger anything.

So when you bring a job across: the days it runs on move into the schedule. The days it must not run on — holidays, freeze windows, month-end — move into the calendar.

One consequence in your favour: an Cronomicon calendar cannot quietly expire and leave a job never running.

In Automate Schedule, where a job runs is settled by its agent or agent environment. In Cronomicon a run's reach is decided by three things together, and the Run dialog shows you all of them before you commit.

This is module M5, and it is the one worth slowing down for. It is where a new operator can do real damage.

Cronomicon snapshots what actually ran: a hash of the script's content at execution time, the effective environment, the scope, the target hosts, and which executor carried it out. Each run carries a trace ID that ties the log, the audit record and the activity entry together.

Practically: when someone asks "what did this job do on the 3rd", there is an exact answer, and "the script changed since then" is visible rather than guessed at.

Script

The script is the executable content, held in Git. Cronomicon reads it, hashes it at run time so the run is reproducible, and detects which variables it references.

Scope

And "allowed" is exact — the scope is a ceiling, not a default. M5 covers what that means when you press Run.

Schedule

Reusable and shared. Schedules also carry activation windows — a start and end date outside which the schedule simply does not fire — and can run at an interval or exactly once.

Env Vars — as a secret reference, not a value

This one has a sharp edge. A job binds the name of a secret, never the secret itself. The value is fetched at dispatch, injected into that run only, and fed to the log redactor so it cannot appear in output.

The practical rule: if you ever find yourself typing a password into a job definition, stop — there is a reference for it.

Workflow

Not a property of any one job. A workflow holds the order, the branching, and the values passed from one step to the next — the equivalent of an Automate Schedule job suite.

The job — its concurrency policy

Allow, Forbid or Queue, set on the job itself rather than on any of the four pieces. It is the equivalent of an Automate Schedule job queue. M6 covers what each answer does.

Yes — any signed-in user

Tags are yours, not Git's. They live only in Cronomicon, survive every sync, and need no special permission. The same is true of tags on scripts, schedules and workflows.

No — commit to Git

The script is the definition. Change it in the repository and let it sync. If the app let you overwrite it, there would be two answers to "what does this job do", and the repository's would be wrong.

Yes — any signed-in user

Annotations are a sidecar, like tags: Cronomicon-only, sync-preserved. This is the right place for "ring the DBA before re-running this" — knowledge that belongs to your team's operation of the job rather than to its definition.

Yes — that is state, not definition

Pausing does not change what the job is, so Git has no opinion about it. Same for resuming, and for stopping a run that is currently going.

No — commit to Git

The scope binding is part of the definition. Changing where a job may run is exactly the kind of change that should be reviewed and recorded, not typed into a form at 2am.

Yes — and it changes nothing permanently

A per-run override applies to that run and no other. It is recorded against the run so anyone reading the history later can see it was not a normal execution. The definition is untouched.

This is the release valve for "just this once", and it is the right tool for that job.

Catalog rows expand in place into a detail panel — runs, bindings, notes, actions — so you keep your filters and your place in the list. Each panel has its own Refresh, which reloads that panel alone.

Every catalog has tabs across the top — All, Running, Success, Failed, Paused — with counts. A tab showing zero is dimmed but still clickable. Tags are yours to apply and filter by, and are usually a faster route to "my team's jobs" than typing.

The Columns menu lets you choose which columns appear and in what order, per table, and it remembers. If you never look at a column, remove it — a narrower table is a faster read, and the setting follows you back.

Change a setting and the This run panel calls it out as a deviation from the job's normal behaviour. Before the run starts, a confirmation lists those deviations back to you — only the deviations, because that is the part worth a second look.

The deviation list is also recorded against the run. Someone reading History next month can see this run was not a normal one, and how.

A job can declare run inputs — questions answered at run time, inherited from the script that declares them. This one declares none, so the section reads none declared.

When a job does declare them, it can be set to warn about missing required answers or to block the run outright. If a run refuses to start over a missing input, that is the job's author telling you the answer genuinely matters.

Every job is bound to a scope, and the scope's host list is the maximum reach of any run of that job. Not a default — a ceiling.

You cannot target a host outside the bound scope. Try it and the run is refused before anything executes, naming the host that is not a member. There is no override for this in the Run dialog; widening reach means changing the scope, which is an administrator's job and leaves an audit trail.

A job can pin a single host. When it does, every run of that job goes to that host only — whether you started it, a schedule fired it, a workflow stepped into it, or a reaction triggered it.

That "every way" matters. It is the whole point of the pin: a job that is safe only on one host must not become unsafe because something other than a person started it.

For a single run you can narrow to specific hosts, or to inventory groups. This narrows only — it can never reach past the scope.

For Ansible jobs this becomes the --limit the playbook runs under, computed the same way for both executors so an Ansible run and an SSH run of the same selection reach the same machines.

One deliberate behaviour worth knowing: if your selection resolves to nothing, the run targets nothing. It does not fall back to the whole scope. A selection that matched nothing is far more likely to be a mistake than an instruction to run everywhere.

The common case. Schedules are reusable, support activation windows (a start and end date outside which nothing fires), and can run on an interval or exactly once instead of on a cron expression.

This is the only path a working calendar can veto.

What M4 walked through. Can be immediate or deferred to a specific time. Calendars do not veto this — if you have decided to run something on a holiday, Cronomicon assumes you meant it.

Your job dependencies. A reaction can distinguish how the first run ended — succeeded, failed, or was killed by someone — and act differently.

Reaction chains are depth-limited so they cannot run away, and every decision to fire is logged, including the ones that decided to fire but could not. If a reaction did not happen, there is a record saying why.

The job runs because the workflow reached it. Its run is linked to the workflow run, so you can read the whole sequence rather than five unrelated rows.

Another system can start a job by calling Cronomicon with a service-account token. A job must explicitly opt in to being triggered this way — being reachable by the API is a decision its author makes, not a default.

Your file dependencies. A runner watches a path; the file must be stable — unchanged in size for a set period — before it counts, so nothing starts on a half-copied file.

Every arrival is recorded in the job's File Arrivals panel, including arrivals that did not start a run and the reason. When someone says "the file landed and nothing happened", that panel is the answer rather than the beginning of an investigation.

This is one of the two things that needs a runner — specifically one on the machine where the files land.

Reads as an actor and a mechanism: Cronomicon (scheduled), or a person's address for a manual run, or a service account for an API trigger. This is the first thing to check when a run happened that you did not expect.

The reactions watching this run. If a failure here is going to cascade into three more jobs, this is where you find that out — ideally before you go and re-run something.

Two different times, and a gap between them is information. A run that queued at 02:00 and started at 02:47 was waiting — for a concurrency gate, for a runner, for the queue ahead of it. If a job "runs late", this pair tells you whether it started late or simply took a long time.

The script's own exit code. Worth pairing with the result: a job can end as Warn and still be considered complete, and — this is the one people do not guess — a warning counts as a success for anything reacting to this run.

If a job habitually exits with warnings and something downstream fires "at random", that is why.

Open a run that is still going and the log updates itself every couple of seconds. You do not have to wait for the job to finish to see what it is doing — which for a long Ansible play is the difference between watching and guessing.

It sticks to the bottom while you are parked there, and stops following the moment you scroll up to read something, then resumes when you scroll back down. When the run reaches its end, tailing switches off by itself.

Secrets are masked — anything injected from the secret store or Vault, and multi-line values such as SSH keys. That masking happens as the log is written, not when you read it, so there is no unredacted copy sitting on disk.

Ordinary environment variables and run inputs are not masked; they are visible, on purpose, because they are usually what you need to see when diagnosing. The rule to carry: if a value should never appear in a log, it belongs in the secret store, not in a variable.

There is a copy button on every log view.

The command or script becomes a file in Git. Decide which repository and path, and which run type it is — bash, PowerShell, Python, Perl, Ansible, Terraform.

If the Automate Schedule job ran several commands in sequence, you have a choice: one script that does all of it, or several jobs composed into a workflow. Prefer the workflow when the steps can fail independently and you would want to see which one broke.

The agent or agent environment becomes a scope. Check whether a suitable scope already exists before making another — scopes are shared, and a proliferation of near-identical ones is how targeting mistakes start.

Two follow-ups: does it need an agency, because the hosts sit in an isolated network? And does it need a runner — which is true if the job watches for files, or if the server cannot reach those hosts directly?

Look for an existing schedule that already says what you need before authoring a new one.

This is the step that goes wrong. If the Automate Schedule job had a calendar, split it in two: the days it should run become part of the cron expression, and only the days it must not run become a working calendar. An Cronomicon calendar cannot schedule anything — if you move the whole calendar across expecting it to drive the job, the job will never run.

Three destinations, and picking the wrong one has consequences:

• Ordinary values → env vars. Visible in logs.
• Passwords, keys, tokens → secrets, bound by reference. Masked in logs, resolved only at dispatch.
• Anything a person supplies at run time → a declared run input.

If a value is currently sitting in the job's parameters and would embarrass you in a log, it is a secret, not a variable.

Job prerequisites become reactions. Note which outcome each one should watch for — success, failure, stopped, or any — because Automate Schedule dependencies and Cronomicon reactions do not always express this the same way.

File dependencies become file-arrival triggers, and need a runner where the files land. Anything triggered by an outside system becomes an API trigger, which means a service account and setting the job to allow external triggering.

A job queue becomes Allow, Forbid or Queue on the job. If it was in a queue to stop it overlapping itself, you almost certainly want Queue — Forbid is the closest literal translation but it drops the work, which is rarely what the queue was for.

Notification lists become notification routing. If the job had a monitor for running too long or not starting on time, that becomes an overdue deadline — which alerts a person without killing the run. Only set a timeout if you genuinely want the run killed.

While you are here, put the on-call contact in the job's notes. It costs nothing and it is the first thing someone looks for at 3am.

Usually an administrator's job, but you are the one who knows which team owns this. Access is granted as a package — a group, a role, and the scopes it applies to — so "who may run this" and "where they may run it" are answered together.