How do I run something every 5 minutes?

Use `*/5 * * * *`. It fires at minutes 0, 5, 10 through 55 of every hour, and because 5 divides 60 the gaps stay even. The same schedule can be spelled out with commas, but a twelve-value list is harder to read and easy to get wrong when you edit it later.

What does the asterisk mean?

Every value in that field: every minute in the minute field, every month in the month field. All five as asterisks (`* * * * *`) runs the job once a minute. The asterisk has a second role too: if either day field is a bare asterisk, the OR rule between the two day fields is disabled, which is why `0 0 13 * *` fires only on the 13th.

How do I schedule something for Friday the 13th?

Cron cannot express it. Writing `0 0 13 * 5` gives you the 13th of every month plus every Friday, roughly 64 runs a year. Schedule the broader condition, usually `0 0 13 * *`, and check the other inside the script before doing any work. The intersection of two day conditions has to be decided by your command, not by the expression.

It uses the system time zone of the machine. Most cloud images default to UTC, so often it is, but that is a convention rather than a rule. Check with `date` on the actual host. To pin it, add `CRON_TZ=Europe/Istanbul` as the first line of the crontab, which affects only the jobs in that file.

Why did my job run twice?

Three candidates. Daylight saving: on the night the clocks go back, the hour between 02:00 and 03:00 occurs twice. Duplicate entries: the same line in both your user crontab and /etc/cron.d/, so check `crontab -l` and that directory separately. And the sneakiest, overlap: cron never waits for the previous run to finish, so a job that occasionally runs long executes concurrently with itself. Wrap it in flock.

Cron Expression Generator - Mustafa Kürşad Başer

Name: Cron Expression Generator
Author: Mustafa Kürşad Başer

Key Takeaways

Standard cron has five fields and no seconds field. A six-field expression belongs to Quartz or Spring, and crontab will not accept it.
When day-of-month and day-of-week are both restricted the job fires when EITHER matches: 0 0 13 * 5 means the 13th of every month AND every Friday, not Friday the 13th.
*/7 on the minute field produces 0, 7, 14 ... 56 and then restarts at 0, so the last gap of each hour is four minutes rather than seven.
Cron runs in the server's local time zone, so a job set for 02:30 is skipped once a year and runs twice once a year wherever DST applies.

The nightly job that ran every minute

The backup was supposed to run at three in the morning. By breakfast it had run 1440 times. The cause is nearly always a swapped field: someone wrote 3 * * * * where 0 3 * * * was intended. The first means "at minute 3 of every hour", the second means "at 03:00 every day". Both are syntactically valid, so crontab accepts the line without a word and the mistake surfaces as a full disk or a billing alert.

Field order, and the missing seconds field

There are five fields, left to right: minute, hour, day of month, month, day of week.

Field	Range	Names accepted
Minute	0-59	none
Hour	0-23	none
Day of month	1-31	none
Month	1-12	JAN ... DEC
Day of week	0-7	SUN ... SAT (0 and 7 are both Sunday)

Day-of-week 7 is an alias for Sunday, as in Vixie cron; this tool normalises it to 0.

There is no seconds field. Most people looking for one have seen a six-field expression somewhere, but that belongs to the Quartz or Spring Scheduler dialect. A Unix crontab will read the sixth token as the beginning of the command and run something nonsensical. This tool rejects six-field expressions and @daily-style macros on purpose: guessing which dialect you meant would produce a schedule that quietly differs from what your cron daemon does, which is the worst possible failure for a scheduling tool.

Step syntax and the wrap-around trap

*/15 expands from the field minimum to the field maximum in increments of 15: 0, 15, 30, 45. That is even because 15 divides 60. Pick a step that does not divide the range and the interval collapses at the boundary, because the step does not carry into the next hour.

bash

1# */7 on the minute field expands to20, 7, 14, 21, 28, 35, 42, 49, 563 4# after 56 the next fire is minute 0 of the following hour,5# so that final gap is four minutes, not seven6 7# the same thing on the hour field, */5:80, 5, 10, 15, 20   # after 20 the next is 0 tomorrow, four hours later

If you genuinely need "every seven minutes", cron cannot express it. Round to a divisor (5, 10, 15, 20, 30) or move the interval logic inside the application and let cron trigger a supervisor. The next-run list in this tool makes the uneven gap visible immediately, which is the fastest way to catch it before it ships.

The day-of-month OR day-of-week rule

This is the genuinely surprising part of cron. Every other field is combined with AND: the minute must match, and the hour, and the month. But when day-of-month and day-of-week are both restricted (neither is a bare *), the relationship becomes OR. If either one matches, the job runs.

bash

10 0 13 * 52# Expected: Friday the 13th (once or twice a year)3# Actual:   the 13th of every month, AND every Friday (~64 times a year)4 50 0 1 * MON6# The 1st of the month, and also every Monday7 80 0 13 * *9# Only the 13th (day-of-week is *, so the OR rule is not in play)

Warning

There is no way to express "Friday the 13th" in a cron expression. The standard workaround is to schedule every Friday with 0 0 * * 5 and test the date on the first line of the script: [ "$(date +\%d)" = "13" ] || exit 0. Note the escaped percent sign; inside a crontab an unescaped % is interpreted as a newline and the rest of the command is fed to the job on stdin.

Time zones and daylight saving

Cron uses the server's system time zone. On a UTC host, 0 9 * * * fires at noon in a UTC+3 region, which is the usual reason an expression tested on a laptop behaves differently in production. Rather than changing the system zone and affecting every other service, put CRON_TZ=Europe/Istanbul at the top of the crontab file: it scopes the zone to the jobs in that file.

Where DST applies, the transition hours are hostile. On the night the clocks go forward, 02:30 never happens, so a job scheduled then is silently skipped. On the night they go back, 02:30 happens twice and the job runs twice. If the work is not idempotent (it charges a card, it sends email, it posts to an external API) move the schedule outside the transition window, for example to 00:30 or after 04:00. Regions on a fixed offset, such as Turkey since 2016, never see this locally, but a server rented in a European region still does.

Frequently Asked Questions

How do I run something every 5 minutes?: Use */5 * * * *. It fires at minutes 0, 5, 10 through 55 of every hour, and because 5 divides 60 the gaps stay even. The same schedule can be spelled out with commas, but a twelve-value list is harder to read and easy to get wrong when you edit it later.
What does the asterisk mean?: Every value in that field: every minute in the minute field, every month in the month field. All five as asterisks (* * * * *) runs the job once a minute. The asterisk has a second role too: if either day field is a bare asterisk, the OR rule between the two day fields is disabled, which is why 0 0 13 * * fires only on the 13th.
How do I schedule something for Friday the 13th?: Cron cannot express it. Writing 0 0 13 * 5 gives you the 13th of every month plus every Friday, roughly 64 runs a year. Schedule the broader condition, usually 0 0 13 * *, and check the other inside the script before doing any work. The intersection of two day conditions has to be decided by your command, not by the expression.
Does cron use UTC?: It uses the system time zone of the machine. Most cloud images default to UTC, so often it is, but that is a convention rather than a rule. Check with date on the actual host. To pin it, add CRON_TZ=Europe/Istanbul as the first line of the crontab, which affects only the jobs in that file.
Why did my job run twice?: Three candidates. Daylight saving: on the night the clocks go back, the hour between 02:00 and 03:00 occurs twice. Duplicate entries: the same line in both your user crontab and /etc/cron.d/, so check crontab -l and that directory separately. And the sneakiest, overlap: cron never waits for the previous run to finish, so a job that occasionally runs long executes concurrently with itself. Wrap it in flock.

Cron Expression Generator

When this runs

Next 5 runs