Crontab Examples Cheatsheet

Crontab Examples Cheatsheet: Common Schedules and Patterns

When you need a schedule quickly, a small set of proven patterns gets you moving without guessing field positions. The expressions below cover the schedules that appear most often in server maintenance, data pipelines, reports, and health checks.¹

Knowing the pattern structure makes adaptation mechanical. Every minute expression is some combination of field values and operators: 0 3 * * * means "at minute 0 of hour 3, every day, every month, every day-of-week." Changing the day-of-week to 1-5 restricts it to weekdays. Changing the hour to */2 runs it every two hours instead of once at 3 AM. The tool above lets you confirm the English description before deploying.

Frequently used schedule patterns

*/5 * * * *: every 5 minutes. 0 * * * *: every hour at minute 0. 0 3 * * *: daily at 3 AM. 0 9 * * 1-5: weekdays at 9 AM. 0 0 1 * *: first of the month at midnight. 0 0 * * 0: every Sunday at midnight. */15 9-17 * * 1-5: every 15 minutes during business hours on weekdays. Each pattern is a starting point for a family of related schedules. Reading these expressions becomes intuitive once you separate the five fields mentally and treat each one as an independent constraint that narrows the trigger window.

Adapting a pattern safely

Changing the day-of-week to 1-5 restricts it to weekdays. Changing the hour to */2 runs it every two hours instead of once at 3 AM. The key principle is to modify only the field that corresponds to the constraint you are adding, leaving the other fields exactly as they were in the proven pattern.

Pick the pattern that already matches the cadence, then adjust the field that represents the business constraint. This avoids rewriting the whole expression and reduces the chance of moving a value into the wrong field. When you limit yourself to one field change per edit, any unexpected behavior in the next run can be traced directly to that single modification.

Practical application: adapting a pattern

Start from the nearest pattern and make one change at a time. To run a backup every night at a different hour, change only the hour field: 0 2 * * * runs at 2 AM. When you need the job to fire only during business hours, add a day-of-week range without touching the time fields you already verified.

Changing one field at a time

To restrict it to weekdays, change only day-of-week: 0 2 * * 1-5. Building on this, to run on specific months (for example, end-of-quarter), change the month field: 0 2 * 3,6,9,12 *. Each change is independent, making debugging straightforward. After each edit, re-read the full expression from left to right to confirm the other fields remain unchanged, because a single misplaced value in the wrong field can alter the entire schedule without producing a syntax error.

Edge-case schedules

Running on the last day of the month has no direct cron syntax.² The standard workaround is 0 0 28-31 * * combined with a script that checks whether tomorrow is the 1st and exits early if not. Running every two hours uses 0 */2 * * *, which fires at hours 0, 2, 4 … 22.³ Consequently, it does not fire at hour 1. Running at 6-month intervals requires listing the target months explicitly: 0 0 1 1,7 *.

These edge cases share a common theme: cron's field syntax can only express periodic patterns, not calendar-aware logic. When a schedule depends on the actual date (last weekday, first Monday, every 6 months), you combine a broad cron trigger with a script-level guard that exits early on non-matching days. This keeps the cron expression simple and pushes the precise calendar check into a tool that handles it naturally.

Business-hours and off-hours scheduling patterns

Business-hours patterns combine range operators in both the hour and day-of-week fields. */5 9-17 * * 1-5 fires every 5 minutes between 9 AM and 5 PM on weekdays. Off-hours maintenance complements this: 0 0-8,18-23 * * * covers midnight to 8 AM and 6 PM to midnight without touching business hours.

First Monday and last Friday of the month

Cron has no built-in nth-weekday syntax for standard Unix crontab.⁴ The standard pattern for "first Monday of the month" uses 0 9 * * 1 (every Monday) with a script-level check: [ $(date +%-d) -le 7 ] || exit 0. For the last Friday, reverse the check: [ $(date +%-d) -ge 25 ] || exit 0. These script-level date checks give you calendar precision that cron's field syntax cannot express directly.

Verifying an adapted expression before deploying

Adapting a cheatsheet pattern introduces risk: changing one field can affect trigger frequency across the entire schedule. After every adaptation, confirm your adapted cron expression fires as expected by pasting the expression in and reading its next 10 trigger times. Confirm both the clock time and the day-of-week match your intent. Skipping this verification step is how a seemingly small edit ends up producing twice as many runs as intended.

For expressions that fire infrequently (monthly or quarterly), extend the preview to the next 20 or 30 triggers to see the full annual distribution. A quarterly job intended to run 4 times per year that the parser shows firing 8 or more times has an unintended interaction between its day-of-month and day-of-week fields. Fix the most permissive field first and re-inspect until the count matches, pasting any adapted pattern from this cheatsheet back in to confirm before deploying.

When to use this

Use this cheatsheet when you need a cron expression quickly and want to start from a known-good pattern rather than compose one from scratch. It is also a useful reference for code review when verifying that a colleague's expression matches the intended schedule.

Examples