Cron expression generator

How to use it#

1. Choose how often: at an interval of minutes or hours, daily, weekly, or monthly.
2. Fill in what that needs, such as the time of day, the weekdays, or the day of the month.
3. Pick the scheduler the expression is for: standard cron, Quartz, Spring, or AWS EventBridge.
4. Check the sentence and the next runs, then copy the expression.

What each choice writes#

Every 15 minutes is */15 * * * *, which runs at minutes 0, 15, 30, and 45 of every hour. Every hour on the hour is 0 * * * *, hourly at 30 minutes past is 30 * * * *, and every 6 hours at half past is 30 */6 * * *, at 00:30, 06:30, 12:30, and 18:30. The steps on offer are the ones that divide the hour or the day evenly. Every 7 minutes can be written, but it runs at 56 and then again at 0, four minutes later, which is rarely what anyone wants.

Daily at 09:30 on weekdays is 30 9 * * 1-5. Weekly on Monday, Wednesday, and Friday at 18:00 is 0 18 * * 1,3,5. Every day at midnight is 0 0 * * *, and monthly on the 1st at midnight is 0 0 1 * *. The sentence under the expression is the same reading the cron expression explainer gives, so what it says is what the expression means, not a description of the choices you made.

Standard cron, Quartz, Spring, and AWS#

Linux crontab, GitHub Actions schedules, and Kubernetes CronJobs all read the same five fields: minute, hour, day of the month, month, and day of the week. That is what the builder writes unless you choose otherwise. The shortest interval GitHub Actions runs a schedule at is every 5 minutes, and a run can start several minutes late when GitHub is busy. Weekdays come out as numbers there, 0 for Sunday, because crontab accepts a name only on its own, not in a range such as MON-FRI.

Quartz and Spring put a seconds field first, which is always 0 here, so the job fires on the minute. Quartz also needs a ? in whichever day field the schedule leaves open. AWS EventBridge keeps the minute first, adds a year on the end, needs the same ?, and is written inside cron(). The three count weekdays differently, so for them the days are written as names, MON-FRI, which each reads the same way. Steps are written from zero, as 0/15, which Quartz and AWS require.

The last day of the month, and months that are too short#

A job on the 31st does not run in April, June, September, or November, and a job on the 30th skips February. Cron does not move it to the last day that month has; it simply finds no matching date. The builder says so when you pick a day after the 28th, and the next runs show which months it lands in.

For the last day of every month, pick Last day. Quartz, Spring, and AWS write that as L. Standard crontab has no way to say it, so the builder asks you to choose another scheduler or another day rather than writing something that will not run. On a Linux server, the usual workaround is to run on days 28 to 31 and have the job check whether tomorrow is the 1st.

Which time zone the times are in#

The expression carries no time zone. It runs in whatever zone the scheduler uses, which for GitHub Actions and AWS EventBridge rules is UTC, and for crontab is the server clock unless CRON_TZ is set. The next runs here are shown in UTC for that reason. A job meant for 09:00 in New York has to be written for 13:00 or 14:00 UTC, depending on daylight saving, or scheduled somewhere that lets you set the zone.