Cron Expression Builder

A cron job may not run for several common reasons. The most frequent issues include incorrect cron syntax, missing permissions, using relative paths instead of absolute paths, or relying on environment variables that are not available in cron’s minimal environment. Cron also requires the command or script to be executable (e.g chmod +x /path/to/script.sh) and accessible by the user running it.

Here is a practical checklist that can help you save time:

• ✅ Make sure the cron expression is valid
• ✅ Use absolute paths for commands and files
• ✅ Ensure the script has execute permissions (chmod +x script.sh)
• ✅ Verify the job runs correctly when executed manually
• ✅ Redirect output and errors to a log file to capture errors
• ✅ Check system logs (e.g. /var/log/syslog or /var/log/cron)
• ✅ Ensure the crontab file ends with a newline (important!)

This cron job example redirects standard output and errors to a log file:

You can then check the /tmp/cron.log file to debug errors or verify execution. For example, if your script echoes a message like Script executed successfully at {datetime}, that message should appear in the log file, confirming that the script was executed correctly by cron.

On Linux systems, system-wide cron jobs are usually defined in the /etc/crontab file or in individual files under the /etc/cron.d/ directory. User-specific crontab files are stored internally by the system, typically under /var/spool/cron/ or /var/spool/cron/crontabs/, and are managed using the crontab command rather than being edited directly. The exact location of user crontab files may vary slightly depending on the Linux distribution, but they are always managed via crontab -e.

Cron is the background service (daemon) that runs on Linux systems and is responsible for executing scheduled tasks. Crontab is the command-line utility and configuration file format used to define those scheduled tasks. In short, cron runs the jobs, while crontab is used to create and manage them.

A user cron job is defined in a user’s crontab and runs as that user, without specifying a username in the cron expression. User cron jobs are created by running crontab -e, which opens the user’s crontab file for editing in the default text editor. Example of a user cron job where no username is specified:

A system-wide cron job is defined in the /etc/crontab file or in files under /etc/cron.d/ and includes an explicit user field that specifies which user the command runs as, example:

In short, user cron jobs run as the crontab owner, while system-wide cron jobs explicitly define the user account used to execute the command by the cron daemon.

To test a cron job manually, run the same command or script from the command line as the same user that cron uses. This helps verify that the command works correctly, has proper permissions, and does not rely on environment variables that may be missing when run by cron.

You can also redirect output and errors to a log file to help with debugging:

This saves both standard output and error messages to /tmp/cron.log. You can then review the log file to confirm whether the job ran successfully or identify any errors.

Yes. The /etc/crontab file should always end with a trailing newline. Cron expects each entry to be terminated by a newline character, and if the last line does not end with one, the final cron job may be ignored without any warning or error message. This behavior also applies to files under /etc/cron.d/, where a missing newline can prevent the last scheduled task from being processed.

To list active cron jobs for the current user on Linux, run the crontab -l command. To view cron jobs for a specific user, use crontab -l -u username with appropriate permissions. This displays all scheduled tasks defined in the user’s crontab. System-wide cron jobs can also be found in the /etc/crontab file and in files under the /etc/cron.d/ directory on most Linux systems.

This is the content of /etc/crontab on an Ubuntu server:

Cron runs jobs in a minimal, non-interactive environment. This means it does not load the user’s shell configuration files (such as .bashrc or .profile) and provides only a limited set of environment variables. As a result, commands that work in an interactive shell may fail in cron if they rely on environment variables, aliases, or relative paths. For this reason, cron jobs should always use absolute paths to commands and files, and explicitly define any required environment variables within the crontab or script.