Cron Examples for Daily Operations

Most cron jobs in production fall into a handful of recognizable shapes: back something up, clean something up, check that something is still alive, or send someone a report. This is a working reference for those shapes — copy-pasteable expressions for common ops tasks, plus a few habits that keep a crontab from turning into a source of 3am pages. For the underlying syntax rules, see Understanding Cron Expressions.

Backups

30 2 * * *        Nightly full backup at 2:30am (low-traffic hour)
0 * * * *         Hourly incremental backup, on the hour
0 4 * * 0         Weekly offsite sync, Sunday at 4am

Pick an off-peak hour deliberately rather than defaulting to midnight — 0 0 * * * is the single most common minute across every crontab on a shared host, which makes it the most common place for backup jobs to contend with log rotation, cache warmers, and everyone else's midnight job for disk I/O at the same moment.

Logs and cleanup

0 0 * * *         Rotate logs at midnight
15 * * * *        Purge temp files hourly, at :15 (offset from the top of the hour)
0 3 1 * *         Purge backups older than N days, 1st of the month at 3am

Monitoring and health checks

*/5 * * * *       Health check every 5 minutes
* * * * *         Every minute — use sparingly, see below
0 8 * * *         Daily summary of the last 24h of alerts, 8am

Every-minute jobs are the ones most likely to overlap themselves: if a run occasionally takes longer than 60 seconds — a slow API, a network blip — the next invocation starts while the last one is still running. See the locking tip below before reaching for * * * * *.

Reports and digests

0 7 * * 1-5       Weekday morning digest, 7am (skips weekends)
0 9 * * 1         Weekly report, Monday at 9am
0 6 1 * *         Monthly billing run, 1st of the month at 6am

Maintenance windows

0 3 * * 0         Weekly service restart, Sunday 3am
0 4 1 1,4,7,10 *  Quarterly task, 1st of Jan/Apr/Jul/Oct at 4am

There's no @quarterly nickname in standard cron — a list of months (1,4,7,10) in the month field is the direct way to express "every three months."

The trap: there is no clean way to say "first Monday of the month"

This comes up constantly, and the commonly-copied fix is wrong. You'll see 0 9 1-7 * 1 suggested as "days 1-7, on a Monday" — but day-of-month and day-of-week together mean OR, not AND (see the trap section in the syntax guide). That expression actually runs on every Monday, plus every day from the 1st through the 7th, regardless of weekday — five to ten extra runs a month that weren't intended:

0 9 1-7 * 1   Looks like "first Monday" — actually fires on:
              Aug 1, 2, 3, 4, 5, 6, 7 (every day in that range)
              AND every other Monday in the month (10th, 17th, 24th, ...)

Standard cron genuinely cannot express "the Nth weekday of the month" on its own. The reliable fix is to schedule the job for every Monday (0 9 * * 1) and have the script itself check whether today's date is 7 or less before doing anything — pushing the one piece of logic cron can't express into the job, instead of trying to fake it with fields that don't mean what they look like they mean.

Stagger jobs instead of stacking them on round numbers

If you're adding several jobs to the same host, avoid defaulting every one of them to :00. Offsetting by a few minutes spreads out CPU, disk, and network load instead of creating a predictable spike every hour:

5 * * * *   Job A — runs at :05
10 * * * *  Job B — runs at :10
15 * * * *  Job C — runs at :15

Guard against overlapping runs

Cron doesn't know or care whether the previous invocation of a job finished — it just launches a new one on schedule. For anything that might occasionally run long, wrap the command in a lock so a slow run doesn't collide with the next scheduled one:

*/5 * * * * /usr/bin/flock -n /tmp/my-job.lock /opt/scripts/my-job.sh

flock -n exits immediately (rather than queueing) if the lock is already held, so an overrunning job skips a cycle instead of stacking up behind itself.

Redirect output, and remember the server's timezone

By default, cron emails a job's output to the crontab owner — which is easy to miss and easy to fill up a mailbox with. Redirect explicitly instead:

0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

And before you deploy any of these, double check what timezone the box is actually running in — a job scheduled assuming local time can quietly run several hours off if the server is set to UTC.

Try it yourself

Adjust any of these without hand-editing fields in Cron Builder, confirm what an expression you've inherited actually does in Cron Parser, and check a full crontab for structural mistakes — including the day-of-month/day-of-week trap above — in Cron Validator. All three run entirely in your browser.