0 23 28-31 * *
At 23:00 on day 28, 29, 30 and 31 of the month
Field by Field
| Field | Value | Matches |
|---|---|---|
| Minute | 0 | 0 |
| Hour | 23 | 23 |
| Day of month | 28-31 | 28, 29, 30, 31 |
| Month | * | every month |
| Day of week | * | every day |
Standard Cron Cannot Express "Last Day"
There is no L in POSIX cron. Quartz and some cloud schedulers support it; crontab,
Kubernetes CronJobs, GitHub Actions and Vercel do not.
The portable pattern is to fire on every candidate day and let the job decide:
``bash
0 23 28-31 * * [ "$(date -d tomorrow +%d)" = "01" ] && /opt/app/month-end.sh
`
The schedule matches the 28th through the 31st; the guard runs the work only when tomorrow
is the 1st. That is correct in February, in leap years, and in 30-day months without any
special-casing.
Why Not Just Use the 1st
Month-end and month-start are different requirements. Closing the books, expiring
subscriptions and taking a final snapshot must happen *inside* the month; reporting on it
happens after. Using the 1st for month-end work loses the last day's data or attributes it
to the wrong period.
Cloud Scheduler Support
AWS EventBridge accepts L in its own cron dialect, as does Quartz. If your platform
supports it, use it — the guard pattern is a workaround, not a preference.
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