cron debugging linux devops scheduling

Solving 'invalid cron expression' and common Cron Syntax Errors

A comprehensive guide to fixing Cron errors like 'invalid cron expression', 'syntax error', and 'cron not running'. Learn how to write schedules correctly for Linux and Quartz.

2026-04-11 Use This Tool

Solving "invalid cron expression" and common Cron Syntax Errors: A Complete Guide

Cron is the standard tool for scheduling repetitive tasks on Unix-like operating systems. Whether you are running a database backup every night or sending a newsletter every Monday, Cron is the engine behind the scenes. However, its "five-field" (or six-field) syntax can be confusing, leading to errors like invalid cron expression, cron syntax error, or the most frustrating one: cron job not running.

In this guide, we will break down the Cron syntax and show you how to fix common scheduling mistakes.


1. Common Cron Error Messages

Unlike a compiler, Cron doesn't always give you a clear error message. Instead, you might see:

  • Crontab validation: crontab: installing new crontab followed by errors in crontab file, can't install.
  • System Logs: ORPHAN (no passwd entry) or CMD (failed to execute).
  • Parsing Libraries: invalid cron expression, Unexpected end of expression, or Number out of range.

2. Top Causes and Solutions

2.1 The "5 vs 6 Fields" Confusion

Standard Linux (Vixie) Cron uses 5 fields: Minute Hour Day Month Weekday

However, many modern libraries (like Quartz in Java or Node-Cron) and some systems (like AWS Lambda or Spring) use 6 fields, adding Seconds at the beginning or Year at the end.

The Mistake: Using a 6-field expression in a standard Linux crontab.

The Solution: Check your environment's documentation. If you are using crontab -e on Linux, use 5 fields. If you are using a specific library, check if it expects seconds.

2.2 Range and Step Errors

Cron uses / for steps (e.g., */5 for every 5 units) and - for ranges. A common mistake is using a number outside the allowed range.

The Mistake:

  • * * 31 2 * (Trying to run on Feb 31st)
  • 60 * * * * (Minute 60 is invalid; use 0-59)
  • * 24 * * * (Hour 24 is invalid; use 0-23)

The Solution: Always ensure your numbers are within these bounds:

  • Minutes: 0-59
  • Hours: 0-23
  • Day of Month: 1-31
  • Month: 1-12 (or JAN-DEC)
  • Day of Week: 0-6 (0 is Sunday, or SUN-SAT)

2.3 The "Day of Month" vs "Day of Week" Trap

In standard Cron, if you specify both a "Day of Month" and a "Day of Week", the task will run when either condition is met (OR logic), not both (AND logic).

The Mistake: 0 0 1 * 1 (You expect it to run only if the 1st of the month is a Monday, but it actually runs every 1st of the month AND every Monday).

The Solution: To achieve "AND" logic, you must use a command check: 0 0 1 * * [ "$(date +\%u)" = "1" ] && /path/to/command

2.4 Environment Variables and Paths

A very common reason for "cron not running" is that Cron executes commands in a very minimal environment. Your PATH might be different, and your .bashrc is not loaded.

The Symptom: The command works when you run it manually but fails in Cron.

The Solution: Always use absolute paths for both the command and any files it touches: /usr/bin/python3 /home/user/script.py >> /home/user/cron.log 2>&1


3. Advanced Troubleshooting

3.1 Percent Signs (%) in Crontab

In a crontab file, the percent sign % has a special meaning (it represents a newline). If your command contains a % (common in date commands), you must escape it with a backslash \%.

The Mistake: 0 0 * * * tar -cvf backup-$(date +%Y-%m-%d).tar /data

The Solution: 0 0 * * * tar -cvf backup-$(date +\%Y-\%m-\%d).tar /data

3.2 Redirecting Output

If a Cron job fails silently, it's usually because the output (stdout/stderr) is being sent to a local mail file you never check. Solution: Always redirect output to a log file to see what went wrong: >> /var/log/myjob.log 2>&1.


4. Prevention and Best Practices

  1. Use a Parser/Generator: Don't guess. Use a visual tool to see exactly when your expression will run.
  2. Comment Your Jobs: Always add a comment above your crontab entry explaining what it does.
  3. Use Absolute Paths: We can't stress this enough. /usr/local/bin/node instead of node.
  4. Test with "Every Minute": When first setting up a job, set it to * * * * * to verify it works, then change it to the actual schedule.

5. FAQ: Frequently Asked Questions

Q: Does 0 or 7 represent Sunday?

A: In most Cron implementations (like Linux), both 0 and 7 represent Sunday. However, some strictly use 0. Using SUN is often clearer.

Q: How do I run a task every 5 minutes?

A: Use the step syntax: */5 * * * *.

Q: Why didn't my Cron job run at 2 AM during Daylight Savings?

A: This is a classic issue. When the clock jumps forward or backward, jobs scheduled during that hour might run twice or not at all. Solution: Avoid scheduling critical tasks between 1 AM and 3 AM, or run your server on UTC time.


6. Quick Check Tool

Confused by asterisks and slashes? Use our Cron Expression Parser & Visualizer. It can:

  • Instantly translate Cron syntax into human-readable English.
  • Calculate the next 5 run times.
  • Support both 5-field and 6-field formats.
  • Validate your expression and highlight syntax errors.

Related Errors