Troubleshoot a “bad minute” error in crontab

“Bad minute” means the crontab parser could not interpret the minute field of a line it treated as a job. The first field of an ordinary five-field schedule must describe minutes from 0 through 59.

The reported line can contain a genuinely invalid minute, but it can also be a continuation line, an uncommented note, or text copied with unusual characters. Inspect the candidate that failed, not only the previously installed table.

Check the first field and line boundaries

These examples are invalid:

60 * * * * /opt/jobs/task.sh
*/0 * * * * /opt/jobs/task.sh
Run this job every morning

Use a valid minute, a positive supported step, and # at the start of comment lines. Keep each job on one physical line. Splitting a command across lines can make its second line look like another schedule.

A valid ten-minute schedule is:

*/10 * * * * /opt/jobs/task.sh

For an hourly job at minute five, use 5 * * * *; that runs once an hour, not every five minutes.

Reveal copied characters

Show line numbers and escaped characters in the candidate file:

nl -ba jobs.cron
LC_ALL=C sed -n 'l' jobs.cron

Look for carriage returns from CRLF files, nonbreaking spaces, full-width punctuation, and a missing final newline. Retype suspicious schedule fields with ordinary ASCII characters. An editor's visual wrapping is harmless; an actual newline in the file is not.

Macro entries such as @daily /opt/jobs/task.sh require an implementation that supports them, and their spelling must be exact. A misspelled macro can produce a parser error.

Keep user and system formats separate

A user crontab contains five time fields and the command. /etc/crontab and supported /etc/cron.d/ files include a username between them:

# System cron file only
0 3 * * * appuser /opt/jobs/task.sh

Adding that username to a user crontab usually makes it part of the command, which can fail later even when the schedule parses. Put comments on separate lines. Cron passes text after the time fields to the shell; it does not provide a general trailing-comment syntax for jobs or environment settings.

Validate without replacing a table

There is no universal syntax-check flag. Check the installed manual first. Versions of Cronie that support -T can check a candidate with:

crontab -T jobs.cron

Debian cron versions documenting -n instead use:

crontab -n jobs.cron

These are alternatives for different implementations, not fallback commands to try blindly. In Cronie, -n has a different purpose. Never substitute a real crontab jobs.cron installation for a dry run without intending to replace the current table.

Common questions

The syntax is valid, but the script still fails. Why? Syntax checks do not verify executable paths, permissions, environment, network access, or output-file ownership.

Can I add a seconds field? Traditional system cron uses five time fields. Schedulers such as Quartz use different formats; do not copy those expressions into a system crontab.

References

• Debian crontab syntax
• Debian crontab command options
• Cronie crontab manual