Like cron, with dependencies, hosts and a live queue
Where cron is the right answer, where it stops being one, and what Xi-Batch adds at that point.
When cron is enough
If you need to run a script at a time, on a machine, and you will notice if it
does not work, cron is a good tool and you should keep using it. We would not
try to persuade you otherwise.
It is universally available, it is robust, and it has done that job well for forty years.
Where it runs out
A control file looks like this:
0 2 * * 0,4 /usr/lib/cron/logchecker
Run that program every Sunday and Thursday at two in the morning. In theory you should be able to express 'the second Tuesday of every month'. In practice, on most systems, you cannot.
More significantly:
Jobs cannot depend on one another
There is no way to say that the ledger post runs only after the transaction load has finished successfully. What people do instead is guess at a time, leave a gap, and hope - or write a wrapper script that becomes its own maintenance problem.
There is no coordination across hosts
A job on one server cannot wait on work completing on another. In a network of servers doing real work, this is the limitation that hurts most.
There is no display
You cannot see what is running, what is queued, or what
failed, without deciphering the output of ps.
There is no load control
Every job that is due starts, whatever else is already running.
There is no intervention
Once cron has started a job, its involvement is
over. You cannot hold it, reprioritise it, or restart it.
Security is limited
There is no concept of what a user may schedule, where, or at what priority.
cron is a timer. It starts the first domino. Everything after that is yours to
arrange.
What a production scheduler has to do
The list below is what Xi-Batch was built to provide, and it is the shape of the requirement rather than a feature list. Any scheduler you evaluate should be measured against it.
| Capability | cron | Xi-Batch |
|---|---|---|
| Time and date triggering | Yes | Yes |
| Repeat by minutes, hours, days, months | Partial | Yes |
| Nth or last working day of the month | Unreliable | Yes |
| Holiday calendars and days to avoid | No | Yes |
| Job-to-job dependencies | No | Yes |
| Dependencies across hosts | No | Yes |
| Trigger on file creation, deletion or change | No | Yes |
| Load levelling | No | Yes |
| Job priorities with per-user ranges | No | Yes |
| Live queue display | No | Yes |
| Hold, release, reprioritise, restart a job | No | Yes |
| Per-user security and access control | Limited | Yes |
| Remote submission without a remote login | No | Yes |
| Audit trail | No | Yes |
| Chargeback accounting | No | Yes |
| Graphical and character interfaces | No | Yes |
| Programmatic API | No | Yes |
It should not be a wrapper around cron
Some scheduling products are little more than a user interface over the standard utilities. Xi-Batch was developed from the ground up and does not rely on any other software product or utility for its operation.
That matters in practice: it is why dependencies, load control and security work
consistently rather than as a layer that anyone with access to crontab can walk
around.
Migration should not be a project
Existing crontab entries convert automatically during installation. Xi-Batch
installs in minutes, makes no kernel modifications, and requires no relational
database. It does not interfere with existing systems, so it can be evaluated
alongside what you have.
All text - help messages, menus, keyboard assignments - is tailorable to your environment, which reduces the retraining that usually makes operations teams resist a change of this kind.
If you already have a message bus
A message bus and a scheduler are often put in the same conversation, and they answer different halves of the question.
A bus is reactive. It carries an event from one application to another, and each consumer decides for itself what to do about it. That is the right design for application-to-application traffic, and where you have one it should stay.
What a bus does not hold is time, or the state of the run as a whole. It has no opinion that the ledger post should have started by half past two, that it is now late, that the extract it depends on failed, or that nothing downstream should be released until someone has looked. Nobody publishes a message saying 'the thing that should have happened did not happen'. That absence is precisely what an operations team needs to be told about.
Xi-Batch works both ways round. It owns the calendar, including the awkward parts - the last working day, the days to avoid, the holiday list - and it also reacts in real time, to a file arriving, a job finishing somewhere else, or a submission from another host. Between those two it holds the dependency graph and the live state of tonight's run, which is the thing an operator can look at, hold, reprioritise and restart.
The two compose. Let the bus carry the events, and let the scheduler decide what is due, what is late, and what may now proceed. Xi-Batch needs no broker of its own to install, license or keep running, which is usually the deciding practical point for a team that already has one bus to look after.
If you are looking at Airflow, Kestra or Rundeck
You are asking a different question and it is worth being clear about it.
Those tools are strong for data pipelines and container-native workloads, and if your work is Python-centric and your team is engineers, they may suit you better. They also bring real operational complexity of their own - the documented migrations to Airflow describe multi-environment Kubernetes deployments as the cost of entry.
Xi-Batch suits business batch on Unix and Linux servers, run by operations staff rather than engineers, with dependencies that cross hosts and a requirement that it keeps working unattended for years.
Next
About Xi-Batch · Xi-Batch case studies · Request an evaluation