Backend Developer

Cron for backend developers: the 5 expressions you'll use in production

Last updated 2026-06-24

Memorize the 5 core cron expressions. Always set the timezone explicitly and guard against overlapping runs with a lock file. These two gotchas are common causes of production cron incidents.

Backend developers schedule recurring jobs with cron, and 5 expressions cover most production jobs: every 5 minutes (*/5 * * * *), hourly (0 * * * *), daily at midnight (0 0 * * *), weekly on Sunday (0 0 * * 0), and monthly on the 1st (0 0 1 * *).

Why this matters for you

The two gotchas that bite in production: timezones and overlapping runs. Cron uses the server's timezone, so a job scheduled at 2 AM runs at 2 AM UTC on a server set to UTC, not your local time. Always set TZ in the crontab or use a UTC-aware scheduler. Overlapping runs happen when a job takes longer than its interval. A 5-minute job on a */5 schedule will pile up if it takes 6 minutes. Use flock or a lock file to prevent concurrent execution.

How the five fields read

The fields are minute, hour, day of month, month and day of week, in that order. A star means every value, a comma lists values (1,15), a hyphen sets a range (1-5), and a slash sets a step (*/15). So 30 2 * * 1-5 runs at 2:30 every weekday morning.

One rule surprises people. When both day of month and day of week are set, classic cron runs the job when either one matches. 0 9 1 * 1 runs on the 1st of every month and on every Monday, not only on Mondays that fall on the 1st. Many implementations also accept 7 for Sunday, but this generator uses 0.

Make failures visible

Cron runs jobs with a minimal environment, so a script that works in your shell can fail on a missing PATH entry. Use absolute paths to binaries and files. Send output somewhere you'll read it, like >> /var/log/report.log 2>&1, or errors disappear. Inside a crontab line, % starts a new line of input, so escape it as \% in commands like date +\%F.

Cron doesn't catch up on runs it missed while the server was off. If a nightly job must still run after downtime, use anacron or a systemd timer with Persistent=true.

Cron in Kubernetes

A Kubernetes CronJob uses the same five fields. Set spec.timeZone to an IANA name like Etc/UTC so the schedule doesn't depend on the controller's local time zone, and set concurrencyPolicy: Forbid to skip a new run while the last one is still going. That's the cluster version of a lock file.

Verdict

Learn the five core expressions, then set the timezone and add a lock file to every job. Those two steps prevent the timezone and overlap problems that bite most often.

Open the Cron Generator

Frequently asked questions

Why didn't my cron job run?

Check the schedule's time zone first, then the job's output. Common causes are a PATH that doesn't include your tools, a script without its execute bit, an unescaped % in the command, and a crontab file without a final newline.

Does cron run jobs it missed while the server was down?

No. Classic cron only checks the current minute. Use anacron or a systemd timer with Persistent=true when a missed run should happen after the next boot.

Is */5 the same as listing 0,5,10 through 55?

Yes. */5 means every fifth minute starting at 0, so it matches 0, 5, 10 and so on up to 55. Steps restart each hour, which is why */7 runs at 56 and then again at 0, only 4 minutes later.