15 Cron Job Examples You Can Copy and Paste Today

Every cron job example boils down to three parts: a schedule, a command, and somewhere for the output to go. Most tutorials stop at the syntax. This one gives you working lines you can drop straight into a crontab, grouped by the jobs developers run every day: backups, cache clears, reports, health checks, cleanups, and syncs.

What a Real Cron Job Example Looks Like

A crontab example always has the same shape. Here's one fully annotated:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Read left to right: 0 2 * * * is the schedule (2:00 AM, every day), /usr/local/bin/backup.sh is the command, and >> /var/log/backup.log 2>&1 redirects both standard output and errors into a log file instead of letting them vanish.

Here's the compact version of the schedule fields — minute, hour, day-of-month, month, day-of-week:

Field	Values	Example
Minute	0–59	0
Hour	0–23	2
Day of month	1–31	*
Month	1–12	*
Day of week	0–6 (Sun=0)	*

That's the entirety of cron syntax you need to read any example below. For step values, ranges, and special strings like @reboot, see Weekly Cron Job Syntax: Every Platform, Every Edge Case.

15 Real Cron Job Examples You Can Copy

Grouped loosely by how often they run, from nightly to every few minutes. Each is a real-world cron job example, not an abstract syntax demo.

Database backup every night at 2 AM

0 2 * * * pg_dump mydb | gzip > /backups/mydb_$(date +\%F).sql.gz 2>> /var/log/pg_backup.log

Dumps the database, compresses it, timestamps the filename, and logs errors separately — an example that needs to survive a bad run.

Clearing application cache every hour

0 * * * * php /var/www/app/artisan cache:clear >> /var/log/cache_clear.log 2>&1

Runs on the hour — a common maintenance task for apps that regenerate stale data faster than you'd want to clear it manually.

Sending a daily report email at 8 AM

0 8 * * * /usr/bin/python3 /opt/scripts/daily_report.py >> /var/log/daily_report.log 2>&1

This example goes beyond sysadmin work — it's business logic. Marketing and ops teams often depend on this exact pattern without knowing it's cron underneath.

Pinging a health check endpoint every 5 minutes

*/5 * * * * curl -fsS https://api.example.com/health >> /var/log/healthcheck.log 2>&1

Hits an endpoint on a step interval. This is precisely the kind of job that fails quietly — curl can exit non-zero for hours before anyone checks the log.

Rotating and compressing logs weekly

0 3 * * 0 /usr/sbin/logrotate /etc/logrotate.d/myapp >> /var/log/logrotate.log 2>&1

Runs every Sunday at 3 AM. A weekly cadence is enough for most apps, and logrotate handles the compression and archiving itself.

Cleaning up temp files every 15 minutes

*/15 * * * * find /tmp/app_cache -type f -mmin +30 -delete

A lightweight, frequent cleanup — no logging needed since find -delete is silent by design, but that also means you'll never know if the directory stops existing.

Syncing files to remote storage every 30 minutes

*/30 * * * * aws s3 sync /data/exports s3://my-bucket/exports >> /var/log/s3_sync.log 2>&1

Relevant to any team running scheduled integrations between local storage and a remote service — S3, GCS, or an internal API.

Running a deploy or cache-warm job on weekdays only

0 7 * * 1-5 /opt/scripts/warm_cache.sh >> /var/log/warm_cache.log 2>&1

The 1-5 day-of-week range restricts this to Monday through Friday at 7 AM — useful for jobs that only matter when staff are online.

Beyond these eight, the same schedule-plus-command-plus-logging pattern covers the rest of the fifteen most teams need: certificate renewal checks (0 4 1 * *), disk space alerts (*/10 * * * *), stale session pruning (30 1 * * *), queue worker restarts (@reboot), CDN cache purges (0 5 * * *), invoice generation (0 6 1 * *), and API token refreshes (0 */6 * * *). Swap in your own script paths and the structure holds.

Writing Your Own: Command + Logging Pattern

Every example above follows one reusable template:

  >>  2>&1

Three rules make this production-safe: always use the full path to your script (cron's environment isn't your shell's), always redirect both stdout and stderr, and always append (>>) rather than overwrite, so you keep history instead of losing it every run. That's the entire pattern worth memorizing — everything else is scheduling detail.

The Part These Examples Don't Show You

Every line above runs blind. Cron doesn't check whether pg_dump actually produced a valid file, whether the report email left the SMTP server, or whether the health check curl got a 200 back. It fires the command at the scheduled time and moves on — success, failure, and silence look identical from cron's point of view.

That's how a cron job failed silently for three weeks becomes the norm rather than the exception: the backup script started throwing a permissions error, the log file filled up with the same repeated line, and nobody opened it until a restore was needed. The deeper mechanics are covered in Cron Job Unix: How It Works and Why It Fails Silently.

Logging tells you what happened after you go looking. It doesn't tell you when to look. That gap is what cron job monitoring closes — tracking execution history, flagging missed runs, and alerting when a job that should have pinged in at 2 AM never checked in. If you want to confirm your crontab syntax is valid before worrying about monitoring, Cron Job Checker: Syntax Validator vs. Execution Monitor walks through that distinction.

Cronevra wraps every scheduled job above — backups, health checks, syncs, reports — with recovery alerts, so a silent failure gets caught the same day instead of the same quarter. Check Pricing to see which plan fits your job count.

Frequently Asked Questions

What is a simple example of a cron job?

A simple cron job example is a scheduled command like 0 * * * * /path/to/script.sh, which runs a script every hour on the hour. The five fields before the command set the minute, hour, day of month, month, and day of week; an asterisk means "every" value for that field.

How do I write a cron job to run a script every day at a specific time?

Set the minute and hour fields to your target time and leave the rest as asterisks — for example, 30 6 * * * /path/to/script.sh runs daily at 6:30 AM. Always use the full path to the script and redirect output to a log file so you can confirm it ran.

What's the difference between a cron job and a crontab entry?

A cron job is the task or script being scheduled; a crontab entry is the specific line in the crontab file that defines when and how that job runs. Every crontab entry describes one cron job, but "cron job" is often used loosely to mean the entry itself.

Can cron jobs run more than one command at a time?

Yes — chain commands with && or ; on the same line, such as 0 1 * * * cd /app && ./backup.sh && ./cleanup.sh. For anything more complex than two or three steps, it's cleaner to put the logic in a shell script and call that single script from cron.

Why does my cron job work when I run it manually but not on schedule?

The most common cause is environment differences — cron runs with a minimal environment and no shell profile, so relative paths, missing PATH variables, or unset environment variables that work in your terminal often fail under cron. Always use absolute paths and explicitly set any required environment variables inside the script.

How do I know if a cron job actually ran or failed silently?

Cron itself won't tell you — it doesn't check exit codes or notify anyone on failure by default. You either need to check logs manually after every run or use a monitoring service that tracks each job's check-ins and alerts you when an expected run doesn't happen.