How to Prompt AI to Write a Cron Expression That Works
Get a correct cron expression from AI every time: the five-field rules, the day-of-month trap, timezone checks, and a prompt that makes it show its work.
A correct cron expression has five fields in this order: minute, hour, day of month, month, day of week. To get one from AI that works, ask for the expression, a field-by-field breakdown, and the next five run times, then check those run times yourself. AI is good at the syntax and unreliable at calendar arithmetic and time zones, which is where cron schedules actually go wrong.
The five fields in thirty seconds
Field | Allowed values |
|---|---|
Minute | 0 to 59 |
Hour | 0 to 23 |
Day of month | 1 to 31 |
Month | 1 to 12 |
Day of week | 0 to 7, where 0 and 7 are both Sunday |
An asterisk means every value. A comma makes a list, a hyphen makes a range, and a slash makes a step, so */15 in the minute field means every 15 minutes. There is no seconds field in standard cron. These rules come from the crontab manual page.
Expression | Meaning |
|---|---|
0 9 * * 1-5 | 09:00, Monday to Friday |
*/15 * * * * | every 15 minutes |
30 2 1 * * | 02:30 on the first day of each month |
0 8,17 * * * | 08:00 and 17:00 every day |
0 0 * * 0 | midnight at the start of Sunday |
The prompt
Name the dialect. Standard five-field cron is not the only format. GitHub Actions uses five fields and runs them in UTC, AWS EventBridge uses six fields with a year, and Quartz-style schedulers add a seconds field. If you do not name the platform, the model picks one for you.
Write a cron expression for: every weekday at 07:30 Europe/Zurich time.
Target: standard five-field cron on a Linux server whose clock is set to UTC.
Constraints: no seconds field, no @ shortcuts, no extensions such as L or #.
Return:
1. The expression.
2. A field-by-field breakdown.
3. The next five run times, starting from Wednesday 8 October 2026 at 09:00 UTC.
4. Anything that would behave differently if the server clock changed.The fourth item makes the model think about time zones and daylight saving before you deploy, instead of after the first missed run.
The day-of-month trap
This is the mistake AI makes most, and the one a quick glance misses. When both the day-of-month and day-of-week fields are restricted, cron runs the job when either one matches, not both. The manual page states it directly. So 0 9 1 * 1 does not mean 09:00 on a Monday that falls on the 1st. It means 09:00 on the 1st of every month and also 09:00 every Monday.
If you need the first Monday of the month, you cannot write it as one standard expression. The usual workaround is to schedule every Monday and let the script exit unless the date is early enough.
#!/usr/bin/env bash
# run weekly from cron, but only act on the first Monday of the month
[ "$(date +%d | sed 's/^0//')" -le 7 ] || exit 0Ask the model for this pattern by name: run weekly, with a guard in the script. Otherwise it will often hand you the broken single expression with a confident explanation.
Time zones and the server clock
Cron runs on the clock of the machine, and many cloud servers are set to UTC. A job written as 07:30 runs at 07:30 UTC, which is 09:30 in Zurich during summer time. Some cron implementations accept a CRON_TZ variable, which the manual page documents, but not every implementation does, so check yours.
Two more traps. Schedules between 02:00 and 03:00 in zones with daylight saving can skip or repeat when the clocks change, so avoid that hour. And a job fixed in UTC drifts by an hour against local time twice a year. Tell the model the server zone and the zone you care about, and ask it to do the conversion in plain sight.
Check the answer in two minutes
Read the breakdown and confirm each field against the table above.
Paste the expression into crontab.guru, which translates it back into plain English. If the English differs from what you asked for, the expression is wrong.
Compare the model's next five run times with a tool. Do not trust its date arithmetic.
Run the command once by hand, as the same user, with a bare environment.
Redirect output to a log file so a failure leaves a trace.
A finished line looks like this, with absolute paths because cron starts jobs with a minimal environment.
30 7 * * 1-5 /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Cron is the simplest scheduler, but it is not the only way to run work on a timer. If you are building an app rather than administering a server, see how scheduled tasks work in an AI-built app. The same demand for a worked check applies when you prompt AI to write a regular expression. Once the job exists, write a runbook for it, and for the general method behind all of these prompts, read the prompt engineering guide.
FAQ
How do I run a cron job every 5 minutes?
Use */5 * * * * in the five-field format. The slash sets a step of five in the minute field, and the asterisks in the other fields mean every hour, day, month, and weekday.
Can cron run a job every 30 seconds?
Not directly. Standard cron has a resolution of one minute. A common workaround is two entries, one that runs the command and one that sleeps for 30 seconds first, or a long-running service with its own timer.
What does 0 0 * * * mean?
Run at minute 0 of hour 0 on every day of every month, which is midnight each day, in the server's time zone.
Why did my cron job not run?
Check four things in order: the server time zone, whether the command uses absolute paths, whether the user has permission to run it, and whether the output log shows an error. Most missed jobs are path or environment problems, not schedule problems.
How did this land?
About the author

Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.


