Cron Schedule Reference
Understand how to schedule jobs on Unix-like systems. The syntax determines when the cron daemon will execute the command.
When Cron Is the Right Tool
Cron is a good fit for repeatable server-side tasks such as backups, cleanup scripts, feed refresh jobs, reports, and health checks. It is less suitable when you need guaranteed execution across many instances or detailed retry and workflow logic.
The Syntax
Five fields separated by space:
* * * * *
│ │ │ │ │
│ │ │ │ └─── Day of Week (0 - 6) (0 to 6 are Sunday to Saturday, or use names)
│ │ │ └───── Month (1 - 12)
│ │ └─────── Day of Month (1 - 31)
│ └───────── Hour (0 - 23)
└─────────── Minute (0 - 59)Common Examples
| Key / Code | Description |
|---|---|
| * * * * * | Every minute |
| 0 * * * * | Every hour (at minute 0) |
| 0 0 * * * | Every day at midnight |
| 0 9 * * 1 | Every Monday at 9:00 AM |
| */15 * * * * | Every 15 minutes |
| 0 0 1,15 * * | At midnight on the 1st and 15th of every month |
Special Strings
| Key / Code | Description |
|---|---|
| @reboot | Run once, at startup |
| @daily | Run once a day (0 0 * * *) |
| @weekly | Run once a week (0 0 * * 0) |
| @monthly | Run once a month (0 0 1 * *) |
Common Cron Mistakes
A common mistake is testing a command manually and assuming cron runs it in the same environment. Cron usually has a minimal PATH, a different working directory, and no interactive shell setup, so scripts should use absolute paths and explicit logging.
Related
Use cron together with common shell commands and file operations on Unix-like systems.
Test and automate HTTP calls that are later run under cron.
Run cleanup, backups, and batch tasks inside containers on a schedule.
Inspect logs and fix environment issues on remote servers when a cron job fails.