Mastering Cron Jobs: The Complete Guide to Scheduling Tasks Without Breaking Production

I once crashed a production server with a single character

I meant to run a cleanup script once at 5 AM. The correct syntax is 0 5 * * *.

I wrote * 5 * * *.

That one character meant the script ran every single minute from 5:00 to 5:59 AM. Sixty times instead of once. The script locked the database. Users couldn't log in. I got paged at 5:30 in the morning.

All because of one character in a scheduling syntax that was designed in 1975.

Cron is ancient technology

The cron utility has been running scheduled tasks on Unix systems for nearly fifty years. That's both impressive and terrifying.

The syntax made sense in an era of limited computing resources and teletypes. Five fields, space-separated, representing minute, hour, day of month, month, and day of week. No labels. No hints. No error messages.

Cron-related questions consistently appear in the most-asked DevOps questions on Stack Overflow. We're all confused by this thing. The fact that it's still the standard after fifty years says more about inertia than about good design.

The fields explained

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-6, Sunday=0)
│ │ │ │ │
* * * * *

I still look this up sometimes. There's no shame in it.

Common patterns I actually use:

• 0 5 * * * — Every day at 5:00 AM
• */15 * * * * — Every 15 minutes
• 0 0 * * 0 — Every Sunday at midnight
• 0 9-17 * * 1-5 — Every hour from 9 AM to 5 PM, weekdays only
• 30 2 1 * * — At 2:30 AM on the first of every month

The special characters add flexibility. An asterisk means every value. A slash means every nth value. A comma means a list of values. A dash means a range. Combine them and you can express almost any schedule.

Silent failure is cron's worst feature

JavaScript throws errors. Python crashes with tracebacks. Cron does nothing.

If your cron expression is wrong, the job just doesn't run. No error message. No notification. Your backup script silently stops working and you don't notice until you need those backups.

If your expression is syntactically valid but semantically wrong, like my asterisk mistake, it runs too often or at the wrong time. Still no warning.

This is why I never write cron expressions by hand anymore. I use a visual generator and then verify the output.

high-performing practices from production experience

Always use absolute paths. Cron doesn't know your shell's PATH variable. Write /usr/bin/node script.js, not just node script.js. The environment cron runs in is minimal. It doesn't have the same PATH as your interactive shell.

Log everything. Append >> /var/log/myjob.log 2>&1 to your cron command to capture output and errors. When something fails, logs are your only clue. Without logging, a failed cron job is invisible.

Use which to find binary paths. Run which node or which python3 in your terminal to get the exact path you need in your crontab.

Test your commands manually first. Before adding a job to crontab, run the exact command in your terminal to verify it works. If it doesn't work manually, it won't work in cron.

Consider timezone. Cron uses server time, not your local time. If your server is in UTC but you're in New York, a 5 AM cron runs at midnight Eastern. Set the timezone explicitly in your crontab or use a tool that handles timezone conversion.

Use monitoring. Services like Cronitor or Healthchecks.io will alert you if a scheduled job doesn't run when expected. This is the only way to catch silent failures before they become problems.

Lock your jobs. If a cron job runs longer than its interval, you'll get overlapping executions. Use a lock file or a tool like flock to prevent this. flock -n /tmp/myjob.lock your-command ensures only one instance runs at a time.

The stakes are real

I've seen teams lose weeks of database backups because a cron job silently failed. I've seen runaway scripts cause massive cloud bills because they ran every minute instead of every hour. I've seen deployment scripts overwrite production data because a timezone mismatch made them run at the wrong time.

Cron syntax isn't just inconvenient. It's a genuine production risk.

The visual approach

The Cron Job Generator handles bidirectional translation.

To build a new schedule, you select the frequency, choose your timing, and get the exact cron syntax. No guessing. No memorizing field positions.

To debug an existing schedule, you paste a cron expression and see plain English. */30 9-17 * * 1-5 becomes "every 30 minutes, 9 AM to 5 PM, Monday through Friday." No more counting asterisks.

Frequently asked questions

What does */5 * * * * mean?

Every 5 minutes. The slash means "every nth" value. So */5 in the minute field means every 5th minute: 0, 5, 10, 15, and so on.

How do I run a cron job every 2 hours?

0 */2 * * * — at minute 0 of every 2nd hour. This runs at midnight, 2 AM, 4 AM, and so on.

Can cron run jobs at random intervals?

No. Cron runs on fixed schedules. If you need random intervals, write a script that sleeps for a random duration and run it as a daemon instead of a cron job.

How do I edit my crontab?

Run crontab -e in your terminal. This opens your crontab in your default editor. Save and exit to install the new schedule. Run crontab -l to list your current jobs.

What's the difference between cron and systemd timers?

Systemd timers are a more modern alternative to cron. They support more complex scheduling, better logging through journald, and dependency management. But cron is simpler and universally available. For basic scheduling, cron is fine. For complex workflows, consider systemd timers.

Final note

Cron syntax isn't going anywhere. It's been the standard for fifty years and it'll be the standard for fifty more. Learn it, use a generator to avoid mistakes, and always log your jobs.

Generate your cron expression with the Cron Job Generator.