Bad Minute crontab error
To understand this error, it's useful to know two rules about crontab files:
Every line in your crontab must comply with the cron specification. The only things allowed are blank lines, declared environment variables, comments, and valid cron job schedule expressions.
The first part of a cron job schedule expression is the minute field.
What causes this error
When you save, crontab checks each line. If the line is not blank, not a variable declaration, and not a comment, it has to start with a valid minute. If it doesn't, you get bad minute.
On Debian and Ubuntu, crontab -e prints a line before the error, then asks if you want to try the edit again:
crontab: installing new crontab
"/tmp/crontab.gLfS38/crontab":10: bad minute
errors in crontab file, can't install.
Do you want to retry the same edit? (y/n)
Answer y and the editor opens again. On Debian and Ubuntu the number is the line before the broken one. The example says 10, so the broken line is 11. cronie usually reports the broken line itself. A line that is only one word, such as notaminute, is that line on Debian and Ubuntu, and the line before it on cronie. A path such as /usr/bin/foo is the other way around. That /tmp/crontab.gLfS38/crontab path is a temporary copy: a file named crontab inside a temporary directory. You only see it from crontab -e. crontab /path/to/file names the file you passed, and it does not ask you to retry.
cronie (Red Hat, Fedora, and cronie installed elsewhere) prints the same bad minute line. Its crontab -e copy is a temporary file, not a directory, named like /tmp/crontab.XXXXXX. The line after bad minute is described in Errors in crontab file, can't install.
@reboot, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly replace the five schedule fields. They are not a bad minute. daily without the @ is. An unknown name after @ is bad time specifier.
Want alerts if your cron jobs stop working?
Monitor your cron jobs with Cronitor to easily collect output, capture errors and alert you when something goes wrong.
Fixing bad minute errors
This type of error could have many causes. Here are some troubleshooting steps to identify and fix the problem.
On Debian and Ubuntu, the number in the message is the line before the broken one. In the example above the message says 10, so read line 11. cronie usually names the broken line. A line that is only one word is the line before it on cronie only. A path is the line before it on Debian and Ubuntu only.
Check for unexpected line breaks in your crontab file. Sometimes you may inadvertently wrap a long line by adding a line break. Cron requires the full schedule and command on a single line.
Good:
0 0 * * * /very/long/example/command/goes/here "with several very long arguments"Bad:
0 0 * * * /very/long/example/command/goes/here "with several very long arguments"On Debian and Ubuntu the command line is a bad minute, and the number is one before that line. On cronie the schedule line with no command is
bad command, notbad minute.If every line begins with a cron schedule, check that the first field is a minute. These are the allowed values:
Value Description 0-59 A minute from 0 through 59. 60is rejected.*Every minute ,A list, for example 1,3,5-A range, for example 1-10/A step after *or a range, for example*/5or1-59/5A step follows
*or a range.*/5is every five minutes.1-59/5is every five minutes starting at minute 1.1/5, a number and a slash with no range, is a bad minute on Debian and Ubuntu cron and on cronie, including RHEL and Fedora.The five fields are shown in Cron job schedule syntax. To check an expression, use Crontab Guru.
Review any comments in your crontab file and make sure each one starts with a
#.A word in the minute position is a bad minute. That includes
exportinexport PATH=/usr/bin. Cron assignments have noexport:PATH=/usr/bin. Those variables are covered in crontab environment variables.If you have verified that your cron expression is correct, and you have examined each line for spurious characters or extra line breaks, it's possible you are dealing with a non-standard version of Cron. Review your local documentation for further guidance on crontab format. You can do this from your command line by running
man 5 crontab.