Cron 'bad minute' Error: Causes and Fixes

What the "bad minute" Error Means

The "bad minute" error in cron is a syntax error that occurs when the cron daemon attempts to read and execute a job from a crontab file. It indicates that an invalid value has been specified in the "minute" field of the schedule.

The full error text in logs typically looks like:

(cron) error (bad minute)

or

CRON[12345]: (username) BAD MINUTE (value)

Context of appearance: The error appears in the system log (/var/log/syslog or /var/log/cron) at the moment cron tries to run the job (usually at the start of each minute). The job itself will not be executed until the syntax is corrected.

The "minute" field in the crontab format is the first of five numbers/special characters in the schedule line. It must adhere to strict rules.

Causes

The "bad minute" error occurs only due to an invalid value in the first field of the schedule. Specific causes:

1. Value outside the 0-59 range. For example, 60, 61, -1, 100.
2. Non-numeric value. For example, sixty, first, * * * * * (if the first field is *, that is correct, but if it's * * with an extra symbol, it will cause an error).
3. Empty field or space instead of a value. For example, * * * * * (space at the beginning) or * * * * * (if the editor replaced a tab).
4. Use of a fractional number. For example, 0.5, 1.5. Only integers are allowed.
5. Invalid combination of range and step. For example, 0-60/5 (range exceeds 59) or */0 (division by zero).
6. Characters that are not part of the crontab syntax. For example, commas without numbers, letters, special symbols in the wrong place.

⚠️ Important: The "minute" field in crontab does not support month or weekday names (those are for the "month" and "day of week" fields). Only numbers 0-59, ranges, lists, and steps.

Solutions

Method 1: Direct crontab editing

The most common and direct method is to find and correct the erroneous line in your user crontab.

1. Open your crontab for editing:

   crontab -e
   

   
   By default, this opens an editor (usually nano or vim). If it's your first time, you may be prompted to choose an editor.
2. Find the line with the error. If you know which job isn't working, find it. If not, review the entire file. The erroneous line will have an invalid value in the first field. Examples of invalid lines:

   60 * * * * /path/to/script.sh     # Error: 60 > 59
   */0 * * * * /path/to/script.sh    # Error: step 0
   -5 * * * * /path/to/script.sh     # Error: negative number
   * * * * *                        # Valid (every minute)
   

   
   Examples of valid lines:

   0 * * * * /path/to/script.sh      # Every hour at minute 0
   */5 * * * * /path/to/script.sh    # Every 5 minutes
   0-30/5 * * * * /path/to/script.sh # Every 5 minutes from 0 to 30
   

3. Correct the minute field to a valid value (0-59, range, step, list). Save the file and exit the editor.
   • In nano: Ctrl+X, then Y (save), Enter (confirm name).
   • In vim: :wq, then Enter.
4. Ensure the crontab is loaded. The crontab -e command automatically checks syntax upon saving and will report an error if one remains. If saving completes without warnings, the syntax is correct.
5. Check the logs in 1-2 minutes to confirm the error is gone:

   grep -i "bad minute" /var/log/syslog
   

Method 2: Validation via crontab -l and external tools

If the crontab is large or you're unsure about the syntax, use additional validation methods.

1. Output the current crontab to a file and check manually:

   crontab -l > mycron.txt
   

   
   Open mycron.txt in any editor and carefully check the first field of each line.
2. Use an online validator for complex schedules. Go to crontab.guru and enter your schedule (the first 5 fields). The service will show how often it runs and highlight errors.
3. Check syntax with the crontab utility (some distributions):

   crontab -c -l  # The -c flag may check syntax (depends on cron version)
   

   
   If the command is unavailable, rely on the logs.

Method 3: Analyze system logs to find the specific line

If you don't know which crontab (user or system) has the error, search the logs.

1. Review cron logs. Depending on your distribution:
   • Ubuntu/Debian:

     sudo grep -i "bad minute" /var/log/syslog
     

   • CentOS/RHEL/Fedora:

     sudo grep -i "bad minute" /var/log/cron
     

   • Systemd-based systems (modern):

     sudo journalctl -u cron -b | grep -i "bad minute"
     # or for crond
     sudo journalctl -u crond -b | grep -i "bad minute"
     

2. The output will show a timestamp and the username whose crontab caused the error. Example:

   Feb 17 10:15:01 server CRON[12345]: (user) BAD MINUTE (60)
   

   
   This means user user has a line in their crontab where the minute field is 60.
3. Access that user's crontab (if it's you, use crontab -e; if another user, use sudo crontab -u username -e) and correct the specified value.

Method 4: Check the system crontab (/etc/crontab) and files in /etc/cron.d/

The error might be in a system schedule, not a user crontab.

1. Check the system crontab:

   sudo cat /etc/crontab
   

   
   The format here differs: after minutes come hours, day of month, month, day of week, USER, then the command. Ensure the minute field is valid.
2. Check additional files in /etc/cron.d/:

   sudo ls /etc/cron.d/
   sudo cat /etc/cron.d/*  # Review each file
   

   
   These files use the same syntax as /etc/crontab (with a user specified). Look for invalid minute values.
3. Fix any errors found using sudo nano or sudo vim.

Prevention

To avoid the "bad minute" error in the future:

• Always verify the 0-59 range for the minute field. Remember: there are no 60 minutes in an hour.
• Use proven patterns:
  • */N — every N minutes (N from 1 to 59).
  • M-N — range from M to N (both within 0-59).
  • M,N,O — list of specific minutes.
  • M-N/K — range with step K.
• Test complex schedules on crontab.guru before adding them to crontab.
• Regularly review cron logs (grep CRON /var/log/syslog) for other warnings.
• When adding new jobs, check syntax immediately after saving crontab. The nano text editor often highlights syntax, but cron performs the final check.
• For critical jobs, add a simple test script that writes to a file, and verify it runs a few minutes after setup.

Following these rules will guarantee you avoid cron syntax errors and ensure reliable scheduler operation.