CRON EXPRESSIONS FOR SCHEDULED WEBHOOKS: A PRACTICAL CHEAT SHEET
Cron expressions for scheduled webhooks: a practical cheat sheet
Every cron expression you actually need for scheduling webhooks — daily digests, business hours, month-end jobs — plus timezone and DST gotchas, all copy-paste ready.
Cron expressions are terse, widely supported, and easy to get subtly wrong. Since every schedule in Recurrence Cloud is a cron expression (plus a timezone), here’s a working cheat sheet for the expressions teams actually use — copy, paste, move on.
The 5-field syntax
┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6, Sun=0)
* * * * *
The expressions you’ll actually use
Every day at 8am — the daily digest:
0 8 * * *
Weekdays at 9am — business-hours jobs:
0 9 * * 1-5
Every 15 minutes — polling a slow-moving external system:
*/15 * * * *
Every 30 minutes during business hours only:
*/30 8-18 * * 1-5
Every Monday at 9am — the weekly report:
0 9 * * 1
First day of the month at 6am — invoice runs:
0 6 1 * *
Every Sunday at 2am — cleanup and maintenance:
0 2 * * 0
First and fifteenth of the month at 7am — semi-monthly payroll-style runs:
0 7 1,15 * *
Every 6 hours — health checks and expirations:
0 */6 * * *
4th of December at 9:30, once a year:
30 9 4 12 *
Timezone and DST gotchas
A cron expression alone is ambiguous — 9am where? Recurrence Cloud lets every schedule carry a timezone, so “0 9 * * 1-5” fires at 9am in the schedule’s zone, not the scheduler’s:
{ "cron": "0 9 * * 1-5", "timezone": "America/New_York" }
Watch out for:
- DST shifts. Wall-clock schedules (9am, not “at 13:00 UTC”) survive daylight saving changes. Prefer wall-clock times and let the scheduler resolve the offset.
- Day-of-week + day-of-month. In classic cron these are OR’d together; if both are restricted, the expression usually means “on either day.” Prefer one or the other when it matters.
0 0 * * *is midnight in the schedule’s timezone, not UTC. If you truly want UTC, set the schedule’s timezone toUTCexplicitly.
Prefer two simple schedules over one clever one
A common mistake is encoding too much logic in a single expression. If a job should run “quarter-hourly on weekdays but hourly on weekends,” run two schedules with different names and payloads:
*/15 * * * 1-5→{ "granularity": "15m" }0 * * * 0,6→{ "granularity": "1h" }
Two simple, observable schedules beat one expression nobody can read — especially when every fire shows up in your activity trail.
Ready to put one to work? Follow the scheduled webhook guide from token to verified delivery, or jump straight into the app.