Question 1

Quartz Cron

Accepted Answer

represents a significant evolution, designed specifically for enterprise software applications built on the Java platform. Quartz expressions require a minimum of six fields and optionally support a seventh. The order is: Seconds, Minute, Hour, Day of Month, Month, Day of Week, and optionally, Year. Because Quartz includes the Seconds field, it allows for sub-minute precision, enabling a job to run every 10 seconds (0/10 * * * * ? *). Quartz also enforces a strict mutual exclusivity rule between the Day of the Month and Day of the Week fields: if one is defined, the other must be populated with the Question Mark (?) operator to explicitly declare it as undefined. This eliminates the confusing "OR" logic found in standard POSIX cron.

Question 2

Why does the Day of the Week field use both 0 and 7 to represent Sunday?

Accepted Answer

This quirk is a historical artifact from the early days of Unix development. Different software systems and cultural calendars disagree on whether the week begins on Sunday or Monday. To accommodate both paradigms without breaking existing scripts, the original developers of cron mapped 0 to Sunday (appealing to zero-indexed programmers) and 1 through 6 for Monday through Saturday. They then mapped 7 to Sunday as well, allowing users who view Monday as day 1 to logically conclude their week with Sunday as day 7. Both values are treated exactly the same by the parsing engine.

Question 3

Can I schedule a cron job to run every second, or every 30 seconds?

Accepted Answer

Using standard POSIX cron (the default on Linux and macOS), you cannot. The absolute minimum resolution of a standard cron expression is one minute. If you need sub-minute execution, you must write a script that loops internally. For example, you can schedule a script to run every minute (* * * * *), and inside that script, execute a command, pause for 30 seconds using the sleep 30 command, and execute the command again. Alternatively, you must abandon standard cron and use a system like Quartz Scheduler or systemd timers, which natively support second-level resolution.

Question 4

What happens if my server is turned off when a cron job is supposed to run?

Accepted Answer

Standard cron has no memory of the past. If a job is scheduled for 3:00 AM, and the server is powered down at 2:55 AM and booted back up at 3:05 AM, the 3:00 AM job is completely missed and will not execute until the next scheduled occurrence. To solve this, Linux distributions offer a supplementary utility called anacron. Anacron does not look at specific times; it looks at intervals (e.g., "run once a day"). When the server boots, anacron checks a timestamp file; if the job hasn't run in the last 24 hours, it will execute it immediately upon boot, ensuring daily maintenance tasks are never permanently skipped due to downtime.

Question 5

Does a cron job generate logs or notify me if it fails?

Accepted Answer

By default, the cron daemon captures the standard output (stdout) and standard error (stderr) of the executed command and attempts to email it to the user account that owns the crontab, using the server's local mail transfer agent (like Sendmail or Postfix). If no mail server is configured, this output is often silently discarded or dumped into a local /var/mail/ file that no one reads. Best practice dictates that you should manually redirect the output of your cron jobs to a specific log file by appending >> /var/log/myjob.log 2>&1 to the end of your command in the crontab.

Question 6

Why is my cron job running correctly in the terminal but failing in the crontab?

Accepted Answer

This is the single most common troubleshooting issue, and it almost always relates to environment variables. When you log into a server as a user, your shell loads a profile (like .bashrc) that sets up your $PATH, allowing the system to find executable programs. The cron daemon executes jobs in a completely stripped-down, non-interactive shell environment with a very minimal $PATH (usually just /usr/bin:/bin). If your script relies on specific environment variables or custom installed software (like Node.js or Python), cron will not find them. You must either provide absolute paths to all executables in your script (e.g., /usr/local/bin/python3 instead of python3) or explicitly define the $PATH at the top of your crontab file.

Question 7

How do I translate an expression to run on the last Friday of every month?

Accepted Answer

In standard POSIX cron, this is impossible to do with the expression syntax alone, because standard cron lacks the "Last" and "Weekday" operators. You must schedule the job to run every Friday (* * * * 5), and then add shell logic to the command itself to check if the current date is within the last 7 days of the month. If you are using Quartz cron or a system that supports advanced operators, you can achieve this elegantly using the L operator combined with the day of the week. In Quartz, the expression 0 0 0 ? * 6L translates perfectly to "Midnight on the last Friday of every month."

Cron Expression Translator

Command Palette