Five characters separated by spaces decide whether your backup runs once at 3am or sixty times between 3:00 and 3:59, and the difference is a single star.
Free hosting tool
Cron Expression Builder
Build a schedule from dropdowns or paste an expression, see it in plain English with the next 5 run times. Nothing you enter is sent to a server.
Both day fields are restricted. Standard cron treats that as OR, not AND: this job runs when the day-of-month matches or when the day-of-week matches. The preview above follows that rule.
Where to paste the finished expression
Run crontab -e on your server and add a line in the form <expression> <command>, for example 0 3 * * * /usr/bin/php /var/www/backup.php. The expression schedules it; everything after is the command that runs. Remember the daemon uses the server's timezone, not yours.
Cron expression builder FAQ
What do the five fields in a cron expression mean?
Left to right: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 mean Sunday). A star means "every", a number pins that field, a slash sets a step (*/15 = every 15), a hyphen sets a range (1-5), and a comma lists values (1,15).
How do day-of-month and day-of-week interact?
This is cron's most misunderstood rule: when BOTH fields are restricted (neither is *), standard cron runs the job if EITHER matches, not both. So "0 0 13 * 5" fires on every 13th of the month AND every Friday, not only on Friday the 13th. This tool's next-run preview follows that standard OR behaviour.
What timezone are the next run times shown in?
Your browser's local timezone. A real cron daemon uses the server's timezone, which is often UTC, so if your server is set differently from your machine, shift the preview accordingly. This is one of the most common reasons a job seems to run at "the wrong time".
Does this work for WordPress cron (WP-Cron)?
WP-Cron uses named intervals (hourly, daily) rather than cron syntax, so these expressions don't paste into WordPress directly. Where they do apply is when you disable WP-Cron and trigger wp-cron.php from a real system crontab, a common performance setup, and that crontab line uses exactly this syntax.
Why does my expression run more often than I expected?
The classic mistake is "* 3 * * *" intending 3am daily: the star in the minute field means EVERY minute, so it runs 60 times between 3:00 and 3:59. For once at 3am you want "0 3 * * *". The plain-English description above the preview exists to catch exactly this before it hits a server.
Is anything I enter here uploaded?
No. Parsing, description, and the next-run simulation all run in your browser. Nothing is sent to a server.
Free cron expression builder by ANUPRESS
Reading the five fields without a cheat sheet
Every cron expression is five fields, left to right: minute, hour, day of month, month, day of week. A star means “every”, so 0 3 * * * reads as “minute 0, hour 3, every day, every month, any weekday”, once a day at 3:00am. The mistake that catches nearly everyone at least once is * 3 * * *: that star in the minute field means every minute, so the job fires sixty times between 3:00 and 3:59. The plain-English readout above exists to make that kind of slip visible before it reaches a server.
The OR rule almost nobody knows about
When both day fields are restricted at once, say 0 0 13 * 5, meant as “Friday the 13th”, standard cron does something surprising: it runs when either field matches, not both. That expression fires on every 13th of the month and on every Friday. It’s in the original cron specification and has tripped up sysadmins for decades, which is why this tool shows an explicit warning plus the actual next run times whenever your expression lands in that situation, the preview list makes the OR behavior visible immediately.
Timezones: where “3am” goes wrong
The next-run preview here uses your browser’s timezone, because that’s the most useful default for checking your own logic. A real cron daemon uses the server’s clock, and most cloud servers run on UTC. If your server is UTC and you’re in Berlin, a 0 3 * * * job runs at 4am or 5am your time depending on daylight saving. When a scheduled job seems to fire at the wrong time, the timezone gap between your machine and the server is the first thing worth checking, before assuming the expression itself is wrong.
The WordPress angle: WP-Cron vs real cron
WordPress ships with WP-Cron, which despite the name doesn’t use cron syntax at all, it piggybacks on page visits, checking for due tasks whenever someone loads your site. On low-traffic sites scheduled posts get delayed; on busy sites the constant checking wastes resources. The common fix is to disable WP-Cron in wp-config.php and instead have the system crontab hit wp-cron.php on a fixed schedule, typically every 5 or 15 minutes, and the line you add to that crontab uses exactly the syntax this tool builds.