Cron Expression Parser

A cron job is a command scheduled to run automatically at a fixed time or on a repeating interval. The name comes from cron, the time-based job scheduler built into Unix and Linux, which has been doing this job since the 1970s. You give cron an expression describing when to run, and it runs your command at every matching moment without anyone being present.

If you have ever wanted a report emailed every Monday morning, a database backed up nightly, or a cache cleared every fifteen minutes, a cron job is the traditional answer.

A cron expression is five fields separated by spaces. Each field says which values it matches, and the job runs whenever the current time matches all of them.

*  *  *  *  *
|  |  |  |  |
|  |  |  |  +-- day of week  (0-7, where 0 and 7 are both Sunday)
|  |  |  +----- month        (1-12)
|  |  +-------- day of month (1-31)
|  +----------- hour         (0-23)
+-------------- minute       (0-59)

Four characters do nearly all the work:

• * means every value. * * * * * runs every minute of every day.

• , lists specific values. 0,30 in the minute field means on the hour and on the half hour.

• - gives a range. 1-5 in the day-of-week field means Monday through Friday.

• / gives a step. */15 in the minute field means every fifteenth minute.

There are also shorthand names for the common cases: @hourly, @daily (also @midnight), @weekly, @monthly and @yearly. The parser above accepts them and shows you the five-field expression each one stands for.

Day of month and day of week together are an OR, not an AND. This is the one that catches almost everybody. 0 0 13 * 5 does not mean "Friday the 13th" — it means "the 13th of the month, *and also* every Friday". If both fields are restricted, cron runs when *either* matches. To get Friday the 13th you need a day-of-week check inside the command itself.

A step that does not divide the range evenly leaves an uneven gap. */7 * * * * looks like "every seven minutes", but the minute field only goes up to 59, so it fires at 0, 7, 14, 21, 28, 35, 42, 49 and 56 — and then again at 0, four minutes later. Steps that divide 60 evenly (2, 3, 4, 5, 6, 10, 12, 15, 20, 30) avoid this.

Cron uses the server's timezone, not yours. A job set for 09:00 runs at 09:00 wherever the machine thinks it is, which is often UTC. Daylight saving makes it worse: in a timezone that observes it, a job scheduled during the skipped hour does not run at all in spring, and may run twice in autumn.

Cron is excellent at one thing: running a command at a time. It has never been good at what happens next.

It has no memory of whether the last run succeeded. It has no retries, so a job that fails because an API was briefly down simply does not happen that day. It has no alerting, so you find out days later. It cannot pass the output of one job into another. And it needs a server that is always on, which means somebody has to own that server.

For a nightly backup on a machine you already run, none of that matters. For a business process — pull yesterday's orders, enrich them, write them to a sheet, notify the team, retry the parts that failed — you end up writing the scheduler's missing features yourself, in the script.

This is the gap Autonoly fills. You get the same schedule you would write in cron, and the parts cron leaves out: retries with backoff when a step fails, alerts when something needs a human, output from one step feeding the next, a run history you can look at, and no server to keep alive.

It also reaches things cron cannot. A cron job can call an API. An Autonoly agent can drive a real browser — log into a portal that has no API, download the report, and carry on — which is where most scheduled business work actually lives.

If you are already comfortable with cron expressions, scheduled execution takes the same syntax. If you would rather describe the schedule in plain English, that works too.