Cron Job FAQ

A cron job is a time-based scheduler in Unix-like operating systems that automatically runs commands or scripts at specified intervals. The name comes from the Greek word for time, 'chronos.' Cron jobs are widely used for automating repetitive tasks such as database backups, log rotation, report generation, sending emails, and system maintenance.

A cron expression is a string of 5 (or 6) fields separated by spaces that defines a schedule for a cron job. Each field represents a unit of time: minute, hour, day of month, month, and day of week. For example, '0 9 * * 1' means 'at 9:00 AM every Monday.' The expression is parsed by the cron daemon to determine when to run the scheduled task.

A standard cron expression has 5 fields in this order: (1) Minute (0–59), (2) Hour (0–23), (3) Day of Month (1–31), (4) Month (1–12), (5) Day of Week (0–7, where both 0 and 7 represent Sunday). Some extended formats add a 6th field for seconds at the beginning, or a year field at the end. AWS EventBridge and some other platforms use a 6-field format with an additional seconds field.

The asterisk (*) is a wildcard that means 'every' or 'any value.' For example, * in the minute field means 'every minute,' * in the hour field means 'every hour,' and so on. '* * * * *' runs every minute of every hour of every day.

The slash (/) defines a step value, meaning 'every N units.' For example, '*/15' in the minute field means 'every 15 minutes' (0, 15, 30, 45). '*/2' in the hour field means 'every 2 hours.' You can also use it with a range: '1-59/2' means every odd minute.

The comma (,) lets you specify multiple discrete values. For example, '1,3,5' in the day-of-week field means 'Monday, Wednesday, and Friday.' '0,30' in the minute field means 'at minute 0 and minute 30.' You can combine commas with ranges: '1-5,7' means 1, 2, 3, 4, 5, and 7.

The hyphen (-) defines a range of values. For example, '9-17' in the hour field means 'every hour from 9 AM to 5 PM inclusive.' '1-5' in the day-of-week field means 'Monday through Friday.' Ranges are always inclusive of both endpoints.

The question mark (?) is used in some cron implementations (like Quartz/Java, AWS EventBridge) to mean 'no specific value.' It's used in either the day-of-month or day-of-week field when you want to specify one but not the other, to avoid conflicts. For example, '0 12 15 * ?' means 'at noon on the 15th of every month, regardless of what day of the week it is.' Standard Linux crontab does not support ?.

These are extended special characters supported by Quartz (Java) and some platforms: L (Last) — in the day-of-month field, 'L' means the last day of the month. In day-of-week, '5L' means the last Friday of the month. W (Weekday) — 'W' finds the nearest weekday to a given date. '15W' means the nearest weekday to the 15th. # (Nth weekday) — '2#3' in day-of-week means the 3rd Monday of the month (2=Monday, 3=third occurrence). Standard Linux crontab does NOT support L, W, or #.

The @ macros are convenient shorthand aliases for common schedules: @yearly (or @annually) = '0 0 1 1 *' (once a year, January 1st at midnight), @monthly = '0 0 1 * *' (midnight on the 1st of each month), @weekly = '0 0 * * 0' (midnight every Sunday), @daily (or @midnight) = '0 0 * * *' (midnight every day), @hourly = '0 * * * *' (at the start of every hour), @reboot = run once at startup. These are supported in standard crontab and many other platforms.

Use '* * * * *' — this runs the job at every minute.

Use '*/5 * * * *' — this runs the job at minute 0, 5, 10, 15, ..., 55 of every hour.

Use '0 * * * *' — this runs at the start (minute 0) of every hour. To run at a specific minute, e.g., 30 minutes past: '30 * * * *'.

Use '0 0 * * *' or the shorthand '@daily'. This runs at 00:00 (midnight) every day.

Use '0 9 * * 1-5' — runs at 9 AM Monday through Friday.

Use '0 0 1 * *' — runs at midnight on the 1st day of every month. For the last day of the month, you'd need a workaround since standard cron doesn't support 'last day' directly (some systems support '28-31 * * *' with a date check).

Standard Linux cron uses the system timezone of the server it runs on. If you need to run at a specific timezone, you can set the CRON_TZ or TZ environment variable in your crontab (supported on most Linux systems): 'CRON_TZ=America/New_York'. Cloud platforms handle timezones differently: GitHub Actions schedules run in UTC. AWS EventBridge uses UTC. Kubernetes CronJobs use the cluster timezone (UTC by default). GCP Cloud Scheduler lets you specify a timezone per job.

In standard Linux cron, if both the day-of-month and day-of-week fields are restricted (not *), the job runs when EITHER condition is true — it's an OR, not an AND. For example, '0 0 1 * 5' runs at midnight on the 1st of every month AND on every Friday. This is a common source of confusion. In Quartz/Java cron, you must use ? in one of the two fields to avoid this ambiguity.

Cron is the daemon (background service) that runs scheduled tasks. Crontab (cron table) is the configuration file where you define those scheduled tasks. 'crontab -e' opens the crontab file for the current user. Each user can have their own crontab file, and there's also a system-wide /etc/crontab and /etc/cron.d/ directory.

Run 'crontab -e' in your terminal. This opens the crontab file for the current user in your default text editor (usually nano or vi). Add a new line for each scheduled job, save and exit. Use 'crontab -l' to list current cron jobs. Use 'crontab -r' to remove all cron jobs (use with care!). Use 'sudo crontab -e' to edit the root crontab.

Use 'crontab -l' to list your own cron jobs. To see system-wide cron jobs, check /etc/crontab, /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.weekly/, and /etc/cron.monthly/. To see if the cron daemon is running: 'systemctl status cron' (Debian/Ubuntu) or 'systemctl status crond' (CentOS/RHEL).

Cron job output is usually mailed to the user unless redirected. To capture output: '0 * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1'. On systemd systems, check logs with 'journalctl -u cron' or 'journalctl -u crond'. On older systems: 'grep CRON /var/log/syslog' (Debian/Ubuntu) or 'grep cron /var/log/cron' (CentOS/RHEL).

Common reasons: (1) PATH issues — cron runs with a minimal environment; use absolute paths for commands and files. (2) Permissions — the script must be executable (chmod +x). (3) Syntax error in crontab — check with 'crontab -l'. (4) Cron daemon not running — 'systemctl status cron'. (5) Environment variables — set them explicitly in crontab or source a profile file. (6) Output not captured — redirect stdout and stderr to a log file. (7) Wrong timezone — cron uses system time, not your local time.

Append stdout and stderr to a log file: '0 * * * * /path/to/command >> /tmp/output.log 2>&1'. Discard all output: '0 * * * * /path/to/command > /dev/null 2>&1'. Send only errors to log: '0 * * * * /path/to/command 2>> /tmp/errors.log'. Without redirection, cron tries to email output to the local user — set MAILTO='' in crontab to disable this.

Standard cron has a 1-minute resolution — you cannot schedule a job to run more frequently than once per minute. To run every 30 seconds, you'd need a workaround: schedule the job every minute with a 30-second sleep: '* * * * * /script.sh; sleep 30; /script.sh'. Some extended cron implementations (Quartz, Fcron) support second-level granularity.

GitHub Actions uses standard 5-field cron syntax in the 'on.schedule.cron' field. Schedules run in UTC. The minimum frequency is every 5 minutes (GitHub enforces this limit). Note that scheduled workflows may run late during high load periods. GitHub Actions cron does NOT support the ? character or @ macros. Example: 'on: { schedule: [{ cron: '0 6 * * 1-5' }] }' — runs at 6 AM UTC every weekday.

Kubernetes CronJobs use standard 5-field cron syntax. The cluster uses UTC by default. Since Kubernetes v1.25+, you can set a timezone per CronJob: 'spec.timeZone: America/New_York'. Important gotchas: CronJobs don't run if more than 100 schedules are missed. Use 'startingDeadlineSeconds' to handle missed runs. Concurrent jobs are controlled by 'concurrencyPolicy' (Allow/Forbid/Replace).

AWS EventBridge uses a 6-field cron format: 'cron(minutes hours day-of-month month day-of-week year)'. All times are UTC. The year field is required. You must use ? in either day-of-month or day-of-week when specifying the other. Examples: 'cron(0 12 * * ? *)' — noon every day, 'cron(15 10 ? * MON-FRI *)' — 10:15 AM every weekday. AWS uses named days (MON, TUE, etc.) and 1-based numbering for days of the week.

Key differences: Linux crontab uses 5 fields (min hour dom month dow), no year, no seconds. Quartz/Java adds seconds as a 6th field at the beginning, and supports ?, L, W, # characters. AWS EventBridge uses 6 fields (min hour dom month dow year), requires ? in one of dom/dow. GitHub Actions uses standard 5-field syntax, UTC only, minimum 5-minute intervals. Kubernetes uses standard 5-field, UTC default, but supports timezone since v1.25. GCP Cloud Scheduler uses standard cron syntax with timezone support.

In Linux crontab, add 'CRON_TZ=America/Los_Angeles' at the top of your crontab file before the job. In Kubernetes CronJobs (v1.25+), use 'spec.timeZone: America/Los_Angeles'. In GCP Cloud Scheduler, set the timezone in the job configuration. In AWS EventBridge, schedules are always UTC — you must manually convert your desired time to UTC. In GitHub Actions, schedules are UTC-only.

Several options: (1) Use CronExpression.tools — paste any expression to see next run times, plain English description, and validation errors. (2) Use the online debugger at /debugger to see the next 10 execution times. (3) Use command-line tools like 'cronexpr' (Go) or Python's 'croniter' library. (4) Use 'crontab -T' (if supported) to test for syntax errors. (5) Use 'systemd-analyze calendar' for systemd timer syntax testing.

Top mistakes: (1) Off-by-one errors — months are 1–12 and days of week are 0–7 (both 0 and 7 = Sunday). (2) Forgetting that day-of-month and day-of-week use OR logic, not AND. (3) Assuming cron uses local time — it uses system time (usually UTC on servers). (4) Using full paths not available in cron's minimal PATH. (5) Forgetting to redirect output — causing mail queue buildup. (6) '*/1' is the same as '*' — it's redundant. (7) Using Quartz syntax (with ?) on Linux crontab — it's not supported.

'/etc/cron.d/' is a directory where system services can place their own crontab files. Files in cron.d must include the username field (6 fields total instead of 5): 'minute hour dom month dow user command'. This is different from user crontabs (via 'crontab -e') which don't need the username. The '/etc/crontab' file and files in /etc/cron.d/ are run as root by default unless a different user is specified.

Use a file lock with 'flock': '* * * * * flock -n /tmp/myjob.lock /path/to/script.sh'. This skips the run if the lock file is held. Alternatively, use a PID file check or the 'run-one' utility. In Kubernetes CronJobs, set 'concurrencyPolicy: Forbid' to skip new runs if the previous one is still running.

Yes, many libraries exist: JavaScript/Node.js: 'croner', 'node-cron', 'cron-parser'. Python: 'croniter', 'apscheduler'. Go: 'robfig/cron'. Java: Quartz Scheduler. Ruby: 'rufus-scheduler'. CronExpression.tools also plans to offer a REST API for Pro users — join the waitlist at /pricing.