A cron job is a scheduled task that runs automatically at a time you define.

Think of it as an alarm clock for your code. You tell it “run this script every day at 6 AM” and it just does it, forever, without you touching anything.

Where does it run?

Cron is built into Linux and macOS. It’s a background service (daemon) called crond that checks every minute if there’s something it needs to run.

You can also run scheduled tasks in the cloud:

• GitHub Actions — uses cron syntax in workflow files
• AWS Lambda + EventBridge
• Vercel Cron Jobs
• Any server with Linux

The cron syntax

A cron expression has 5 fields:

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

Examples:

Expression	Meaning
0 6 * * *	Every day at 6:00 AM
*/15 * * * *	Every 15 minutes
0 9 * * 1	Every Monday at 9:00 AM
0 0 1 * *	First day of every month at midnight
15 */2 * * *	Every 2 hours at :15

For a full reference, check the Cron Syntax Cheat Sheet.

Setting up a cron job on Linux/macOS

# Open your crontab (personal cron schedule)
crontab -e

# Add a line like this:
0 6 * * * /usr/bin/python3 /home/user/scripts/backup.py

# Save and exit. It's now scheduled.

Check your current cron jobs:

crontab -l

Cron jobs in GitHub Actions

You don’t need a server to run cron jobs. GitHub Actions supports cron schedules:

on:
  schedule:
    - cron: '15 */2 * * *'  # Every 2 hours at :15

This is how many developers run automated tasks for free — monitoring scripts, daily builds, data collection. The schedule uses the same cron syntax, and GitHub runs it on their servers.

See the GitHub Actions Cheat Sheet for more workflow examples.

Common use cases

• Backups — back up your database every night
• Monitoring — check if your website is up every 5 minutes
• Reports — generate and email a daily report
• Cleanup — delete old log files weekly
• Content — publish scheduled blog posts at a set time
• Scraping — collect data from websites on a schedule

Common gotchas

• Timezone — cron uses the server’s timezone (UTC on most cloud servers). GitHub Actions always uses UTC.
• PATH — cron runs with a minimal PATH. Use full paths to executables (/usr/bin/python3 not just python3).
• Output — cron swallows output by default. Redirect to a log file: 0 6 * * * /path/to/script.py >> /var/log/myjob.log 2>&1
• Overlapping — if your job takes longer than the interval, you’ll get overlapping runs. Use a lock file to prevent this.

FAQ

Can I run cron jobs on Windows?

Windows doesn’t have cron, but it has Task Scheduler which serves the same purpose. You can also use WSL (Windows Subsystem for Linux) to get native cron support. For cross-platform scheduled tasks, cloud-based solutions like GitHub Actions or AWS EventBridge work regardless of your local OS.

What happens if my server reboots — do I lose my cron jobs?

No — cron jobs are stored in crontab files that persist across reboots. The cron daemon starts automatically when the system boots and reads the saved schedules. However, any job that was supposed to run during downtime will be skipped entirely (cron doesn’t “catch up” on missed runs).

How do I prevent a cron job from running if the previous run hasn’t finished?

Use a lock file (also called a PID file). At the start of your script, check if the lock file exists — if it does, exit immediately. If not, create the lock file, do your work, then delete it. Tools like flock on Linux make this a one-liner: flock -n /tmp/myjob.lock /path/to/script.sh.

Related: Bash Cheat Sheet