Cron test: what a crontab expression will actually run
A cron test shows what a crontab expression means and when it next runs. The day-of-month and day-of-week fields combine with OR, which is why schedules fire more often than you wrote.
A cron test answers “when does this line run?”, which is a different question from “did the job actually run?”. People look up “cron test” and “crontab test” because the five fields are easy to misread and the mistake only shows up at 3am, or not at all. The expression tester on this site parses the line in your browser, describes it in a sentence, and lists the next five runs. Nothing is sent to a server.
The five fields, in the order cron reads them
| Field | Range | The trap |
|---|---|---|
| Minute | 0–59 | There is no seconds field in standard cron. Every 30 seconds is not an expression you can write portably. |
| Hour | 0–23 | The clock is the machine’s local time, which on a server is often UTC. This tester previews runs in your browser’s timezone and says so. |
| Day of month | 1–31 | Combined with day-of-week using OR when both are restricted. See below. |
| Month | 1–12 or JAN–DEC | Names are case-insensitive. A day that does not exist, such as 30 February, never runs. |
| Day of week | 0–7 or SUN–SAT | 0 and 7 both mean Sunday. |
The syntax on top of those fields is small. * is every value. 1,15,30 is a list. 9-17 is an inclusive range. */15 is every 15th value from the start of the field. 0-30/10 is every 10th value inside that range.
Crontab test: the OR that surprises people
When day-of-month and day-of-week are both something other than *, cron runs the job when either field matches. So 0 0 13 * 5 means midnight on the 13th, and also midnight on every Friday. It does not mean Friday the 13th. Cron cannot express “Friday the 13th”. If you need that, the job itself has to check the date and exit.
A cron test does not tell you the job ran
“Cronjob monitoring” is the other problem. Cron produces no error when a line is never invoked: the crontab was lost in a migration, the daemon is not running, the script works in your shell and fails under cron’s empty environment. A correct expression is necessary and not sufficient. The way to hear about a missed run is a heartbeat: the job calls a URL after the work succeeds, and you get alerted when that call does not arrive inside the grace period.
Heartbeat monitors are on the paid plans, from Solo upward. The free plan covers HTTP, port and ping only. The call itself is a GET or POST to https://api.hypermonitors.com/v1/heartbeat/YOUR_TOKEN, placed after the work so a failed job does not ping. The longer walkthrough of grace periods, exit codes and containers is in the cron monitoring article.