Cron Jobs: A Complete Guide for Developers Who Actually Use Them

Admit it: every time you write a cron expression, you have to look up the order of the fields. Minute, hour, day, month, weekday. Or is it weekday before month? After three years of writing cron jobs, you still check.

This guide is the one you actually keep open.

The Syntax, Explained Once and For All

Five fields, left to right:

• Field 1: MINUTE (0-59)
• Field 2: HOUR (0-23, where 0 is midnight)
• Field 3: DAY OF MONTH (1-31)
• Field 4: MONTH (1-12)
• Field 5: DAY OF WEEK (0-6, Sunday=0, or use SUN, MON, TUE...)

Then your command.

The 10 Cron Schedules You'll Use 90% of the Time

• Every minute: * * * * *
• Every 5 minutes: */5 * * * *
• Every hour: 0 * * * * (at :00 of every hour)
• Every 6 hours: 0 */6 * * * (at midnight, 6am, noon, 6pm)
• Daily at midnight: 0 0 * * *
• Daily at 3:30am: 30 3 * * *
• Weekly (Sunday at midnight): 0 0 * * 0
• Every Monday at 9am: 0 9 * * MON
• First day of month at midnight: 0 0 1 * *
• Last day of month (workaround): 0 0 28-31 * * [command] || true

The Timezone Problem

Cron runs in the system timezone. If your server is UTC and you want something at '9am for your New York users', that's 14:00 UTC (or 13:00 during EDT). This catches people every time there's a daylight saving transition — a job that ran at 9am suddenly runs at 8am or 10am for a week.

Modern solutions: use a job scheduler that's timezone-aware (like node-cron with TZ support), or put a timezone conversion into your script.

Always Log Your Cron Jobs

By default, cron sends job output to the local mailbox of the user running the job. Nobody reads that. Redirect output explicitly:

30 3 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

The 2>&1 at the end redirects stderr to stdout, so errors show up in the log file too. Otherwise you're debugging blind.

When Cron Is the Wrong Tool

Cron doesn't handle missed runs (if the server was off during the scheduled time), concurrent execution (it'll start another instance even if the previous one is still running), dependencies between jobs, or retries on failure. For anything beyond simple one-shot scripts, look at proper job schedulers: Sidekiq, Celery, Temporal, or even GitHub Actions with scheduled workflows.