Question 1

What's the difference between cron syntax on Linux vs. AWS EventBridge vs. GitHub Actions?

Accepted Answer

Linux crontab uses 5 fields: minute(0-59) hour(0-23) day-of-month(1-31) month(1-12) day-of-week(0-7, where both 0 and 7 are Sunday). This is the POSIX specification per IEEE Std 1003.1. AWS EventBridge uses 6 fields: minute hour day-of-month month day-of-week year. The critical difference from Linux: in AWS EventBridge, you must use ? (no specific value) in either day-of-month or day-of-week — you cannot specify both, because EventBridge does not allow conflicting day-based constraints. So `0 12 * * ?` (noon every day) is valid EventBridge syntax; `0 12 * * *` is not. GitHub Actions schedule uses 5-field POSIX cron syntax, but the schedule always runs in UTC — there is no way to configure a GitHub Actions cron schedule to a non-UTC timezone. Quartz (used in Java/Spring applications) adds a seconds field at position 0, making it: second(0-59) minute(0-59) hour(0-23) day-of-month(1-31) month(1-12) day-of-week(0-7). Quartz also supports L (last), W (nearest weekday), and # (nth occurrence) special characters that are not available in POSIX or GitHub Actions cron. Kubernetes CronJob uses 5-field POSIX cron (same as Linux crontab) with an optional @timezone annotation on the schedule field.

Question 2

Why does day-of-week have both 0 and 7 as Sunday?

Accepted Answer

The POSIX specification (IEEE Std 1003.1) defines day-of-week as a range from 0 to 7 and explicitly states that both 0 and 7 represent Sunday. This is historical: in older Unix implementations (including the original cron written by Brian Kernighan), day-of-week was 0-indexed starting with Sunday. Some implementations later used 1-indexed starting with Monday. Vixie cron (Paul Vixie, 1988) — the reference implementation behind most Linux cron daemons — accepts both 0 and 7 for Sunday to accommodate both conventions and avoid breaking existing crontabs. In practice, 0 (Sunday) through 6 (Saturday) is the most common convention on Linux systems. Named day abbreviations (SUN, MON, TUE, WED, THU, FRI, SAT) are also accepted by most implementations and avoid the ambiguity entirely. AWS EventBridge uses 1 (Sunday) through 7 (Saturday) — a completely different convention from POSIX — which is one of the most common sources of off-by-one-day bugs when migrating cron expressions from Linux to AWS.

Question 3

What does the L character mean in Quartz cron?

Accepted Answer

L stands for 'last' and is a Quartz-specific special character not available in POSIX cron. In the day-of-month field, L means 'the last day of the month.' So `0 0 L * ?` runs at midnight on the last day of every month — January 31, February 28 (or 29 in leap years), March 31, and so on. The L character knows the length of the current month and automatically adjusts. In the day-of-week field, L means 'the last X day of the month.' For example, `0 0 ? * 6L` runs on the last Friday of every month (assuming day-of-week 6 = Friday in your Quartz configuration). You can also combine L with an offset: `0 0 L-3 * ?` runs three days before the last day of the month. L is not available in Linux crontab, GitHub Actions cron, or AWS EventBridge cron expressions — those platforms have no concept of 'last day of month' in their cron fields.

Question 4

How do I schedule a job for the last day of the month?

Accepted Answer

If you are using Quartz (Java, Spring): use L in the day-of-month field. `0 0 L * ?` runs at midnight on the last day of every month. If you are using Linux crontab or Kubernetes CronJob (POSIX cron): there is no native 'last day of month' field. The standard workaround is to run at midnight on the 28th, 29th, 30th, and 31st and check in your script whether tomorrow is the first of the month. Example: `0 0 28-31 * * [ $(date -d tomorrow +%d) = 01 ] && your-script.sh`. Alternatively, run on the 1st of each month and process the previous month's data. If you are using AWS EventBridge: EventBridge does not support a 'last day of month' expression. EventBridge added a special 'last-day-of-month' support via L in its Quartz-inspired syntax — `cron(0 0 L * ? *)` is valid EventBridge syntax. Note that EventBridge cron includes a year field (positions: minute hour dom month dow year). Always test last-day-of-month logic against months with 28, 29, 30, and 31 days in your staging environment before production deployment.

Question 5

Can I run a cron job every 5 minutes between 9am and 5pm?

Accepted Answer

Yes. The expression is `*/5 9-17 * * *` for POSIX/Linux crontab. Field breakdown: `*/5` in the minute field means 'every 5 minutes' (0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55); `9-17` in the hour field means 'hours 9 through 17 inclusive' (9am, 10am, 11am, 12pm, 1pm, 2pm, 3pm, 4pm, 5pm). This expression will run at 9:00, 9:05, 9:10 ... 9:55, 10:00, 10:05 ... 17:55 on every day of every month. Note: the last run within an hour is at :55, so the expression runs up to 17:55 (5:55pm), not exactly at 5:00pm and stopping. If you want it to stop at exactly 5:00pm (inclusive), use `*/5 9-16 * * *` for 9am–4:55pm, then add `0 17 * * *` as a separate cron for exactly 5:00pm. For AWS EventBridge, the equivalent is `*/5 9-17 * * ? *` (adding the required year field and ? for day-of-week). For GitHub Actions: `*/5 9-17 * * *` (same as POSIX, but in UTC — adjust the 9-17 range to the equivalent UTC hours for your timezone).

Question 6

Why does my cron job not run at midnight on the 31st?

Accepted Answer

If your cron expression is `0 0 31 * *`, it schedules a job to run at midnight on the 31st of every month. But not every month has a 31st. Months with only 28 or 29 days (February) or 30 days (April, June, September, November) will never trigger the expression. The POSIX specification is explicit: if the day-of-month value is out of range for a given month, the job simply does not run that month — cron daemons do not roll over to the next valid day. This is a frequent source of 'my monthly job hasn't run' bugs. Common fixes: (1) For end-of-month jobs, use the L character in Quartz or a script-side date check in POSIX cron (see the 'last day of month' FAQ above). (2) If you intend to run once a month regardless of day, use `0 0 1 * *` (the 1st of every month, which always exists). (3) If you want to run on the 28th of every month (the safest date that always exists), use `0 0 28 * *`.

Question 7

What timezone does cron use and how do I change it?

Accepted Answer

Linux crontab runs in the timezone of the user who owns the crontab file, which is typically the system's local timezone set in /etc/localtime. To change the timezone for a specific crontab, add `CRON_TZ=America/Chicago` (or any IANA timezone name) at the top of the crontab file before any scheduled entries. Modern versions of cron (crond on CentOS/RHEL, cron on Debian/Ubuntu) support CRON_TZ; older versions may not. You can also use `MAILTO=` and `SHELL=` variables in the same file. The critical production pattern: always run cron servers in UTC (`TZ=UTC` at the OS level or `CRON_TZ=UTC` in the crontab) and adjust your expressions to UTC times. This avoids the Daylight Saving Time problem — a job scheduled for `0 2 * * *` in a DST-observing timezone will either skip the 2:00am-3:00am window entirely in spring (when clocks spring forward) or run twice in fall (when clocks fall back). UTC has no DST transitions. GitHub Actions always runs cron schedules in UTC and does not support timezone configuration. AWS EventBridge runs cron in UTC by default; you can specify a timezone in the EventBridge Scheduler (not EventBridge Rules) using a separate timezone parameter.

Question 8

What's the difference between @reboot and a minute 0 every hour expression?

Accepted Answer

`@reboot` is a non-standard but widely supported special string in Vixie cron and compatible daemons (crond on Linux, cron on macOS, launchd cron compatibility layer). It runs the specified command once immediately after the cron daemon starts — which on a typical Linux system means once after system boot, hence the name. It is not the same as `0 * * * *` (which runs at minute 0 of every hour, 24 times a day). `@reboot` runs exactly once per daemon startup. Other similar special strings: `@yearly` = `0 0 1 1 *` (once per year, Jan 1 at midnight); `@monthly` = `0 0 1 * *` (first of each month at midnight); `@weekly` = `0 0 * * 0` (every Sunday at midnight); `@daily` = `0 0 * * *` (every day at midnight); `@hourly` = `0 * * * *` (every hour at minute 0). These special strings are recognized by Vixie cron and most Linux distributions but are NOT part of the POSIX IEEE Std 1003.1 specification — AWS EventBridge and GitHub Actions do not support them. `@reboot` is also not computable as a 'next execution time' because it depends on system state rather than a time-based schedule.

Cron Expression Builder & Validator

Inputs coming in next batch

Frequently asked questions