Why is the 1st the standard choice for monthly cron jobs?

It's the only day-of-month value that exists in every month regardless of length, making it the only fixed date that guarantees exactly 12 runs a year with zero silent skips.

How do I run a job on the first business day of the month instead?

Standard cron can't express this directly — schedule the job to run daily near the start of the month and add logic in the script to check whether today is the first weekday, exiting early otherwise.

Is this the same as the every-month cron page?

Yes, functionally — 'every month' and 'first day of month' both commonly resolve to 0 0 1 * *. This page focuses specifically on the calendar-boundary use case and its edge cases.

Cron: First Day of the Month

0 0 1 * * fires at midnight on the 1st of every calendar month — the day-of-month field pinned to 1 is the only fixed date that reliably exists in every month, from 28-day February to 31-day months. It's the anchor point for billing cycles, quota resets, and monthly archival jobs.

0 0 1 * *

Try it in Cron Parser

Examples & Variations

0 0 1 * *

Midnight, 1st of every month

Try it

0 9 1 * *

9:00 AM, 1st of every month

Try it

0 0 1 1,4,7,10 *

1st of every quarter

Try it

Common Mistakes

Choosing a day-of-month other than 1 for something meant to run monthly without exception — days like 29, 30, or 31 don't exist in every month, silently skipping short months.
Assuming 'first day of month' and 'first business day of month' are the same — if the 1st falls on a weekend, this schedule still fires that day; adjusting to the nearest weekday requires application logic.
Running billing-critical jobs with no retry or alerting — a missed 1st-of-month run for something like invoice generation can cascade into real financial impact before anyone notices.

Best Practices

Day 1 is the only universally safe fixed date for a true 'every month, no exceptions' schedule — use it as the anchor for anything that must never skip a month.
For 'first business day' semantics, run daily and check the date in your script, since standard cron can't express 'nearest weekday' (that's Quartz's W character, not available in POSIX cron).
Add explicit success/failure alerting for billing and financial jobs tied to month boundaries — the cost of a silent miss is usually much higher than for more frequent schedules.

Frequently Asked Questions

Why is the 1st the standard choice for monthly cron jobs?: It's the only day-of-month value that exists in every month regardless of length, making it the only fixed date that guarantees exactly 12 runs a year with zero silent skips.
How do I run a job on the first business day of the month instead?: Standard cron can't express this directly — schedule the job to run daily near the start of the month and add logic in the script to check whether today is the first weekday, exiting early otherwise.
Is this the same as the every-month cron page?: Yes, functionally — 'every month' and 'first day of month' both commonly resolve to 0 0 1 * *. This page focuses specifically on the calendar-boundary use case and its edge cases.

Related Tools

Cron Parser

Translate cron expressions to plain English

Cron Cheat Sheet

Quick reference for cron syntax, special characters, and shortcuts

Cron Examples Library

Browse and search common cron expression examples

Cron: Weekends Only

The cron expression for weekends only (Saturday and Sunday) is 0 0 * * 0,6. See weekend-only scheduling examples and use cases.

Cron: Last Day of the Month

Standard cron can't directly express 'last day of month.' See the common workaround using 28-31 * * plus a date check, and the Quartz L character alternative.

Cron: Every Midnight

The cron expression for every midnight is 0 0 * * *, running once daily at 00:00. See midnight scheduling examples and best practices.