0 8 * * 1
At 08:00 on Monday
Field by Field
| Field | Value | Matches |
|---|---|---|
| Minute | 0 | 0 |
| Hour | 8 | 8 |
| Day of month | * | every day |
| Month | * | every month |
| Day of week | 1 | 1 |
Monday Is 1
The expression fires at 08:00 every Monday. Named form 0 8 * * MON reads better in a
crontab someone else will maintain.
The Reporting Window
A Monday morning digest almost always wants "the seven days ending last night", not "since the last run". Those differ the moment a run is missed: a skipped Monday means the next digest silently omits a week.
Compute the window from the current date, and make it explicit:
``bash
0 8 * * 1 /opt/app/digest.sh --from "$(date -d 'last monday -7 days' +%F)" --to "$(date -d 'yesterday' +%F)"
`
Eight in the Morning Is a Deliberate Choice
Early enough to be in the inbox before the working day starts, late enough that overnight
batch jobs have finished producing the data it reads. If your nightly aggregation finishes at
07:30, an 08:00 digest is fine; if it finishes at 08:15, the digest reports on stale numbers
every single week.
Check the dependency's actual finish time, not its scheduled start.
Time Zones
Standard crontab evaluates in system local time. Vercel Cron, GitHub Actions, Kubernetes
CronJobs and AWS EventBridge all evaluate in UTC. If converting your local time crosses
midnight, the day-of-week field shifts too — weekdays at 5pm in UTC-07:00 is
0 0 * * 2-6, not 0 0 * * 1-5.
The Day-Field Trap
When both the day-of-month and day-of-week fields are restricted, cron matches either,
not both. 0 0 13 * 5 runs on every 13th *and* every Friday — not Friday the 13th. Leave
one of them as * unless you genuinely want the union.
Other Common Schedules
| Expression | Runs |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
*/15 * * * * | Every 15 minutes |
0 * * * * | Every hour, on the hour |
0 0 * * * | Every day at midnight |
0 9 * * * | Every day at 9am |
0 9 * * 1-5 | Weekdays at 9am |
0 9 * * 1 | Every Monday at 9am |
Making the Job Safe
Assume double firing. DST transitions, restarts and retries all cause it. Make the job
idempotent rather than assuming exactly-once.
- Assume overlap. Cron starts the next run whether or not the last one finished. Take a
lock.
Avoid:00`. Every hourly job on the internet fires at the top of the hour; a random
- Log the start and end. A cron job that silently stops running is invisible until