Cron First Day of the Month

0 2 1 * *

At 02:00 on day 1 of the month

Field by Field

Field	Value	Matches
Minute	0	0
Hour	2	2
Day of month	1	1
Month	*	every month
Day of week	*	every day

Twelve Runs a Year

0 2 1 * * fires at 02:00 on the 1st of every month. The day-of-week field stays *, which is essential — restricting both day fields makes cron match *either*, so 0 2 1 * 1 runs on every 1st and every Monday.

The two-hour offset from midnight is deliberate, and the next section is why.

Month Boundaries Are Where Reporting Breaks

A job running at 00:00 on the 1st is reporting on the month that just ended, and it is running in the instant the new month begins. Two things go wrong:

• Off-by-one month. Compute the reporting period as "the month before now", never "the

current month", or every report will be empty.

• Late-arriving data. Events written at 23:59:58 on the last day may not be committed,

replicated or ingested by 00:00:00. Two hours of slack costs nothing and removes the whole class of problem, which is why this page uses 0 2 1 * * rather than 0 0 1 * *.

Billing Runs Want Idempotency Most of All

A monthly billing job that runs twice charges twice. Key every charge on (customer, period) and make a repeat a no-op — this is worth more than any amount of scheduler care, because retries and restarts will happen regardless.

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

minute spreads load on shared APIs.

• Log the start and end. A cron job that silently stops running is invisible until

someone notices the missing output.