cron Expression Checker | Plain-Language Meaning, Next Run Times, Japan Time ⇄ UTC Conversion (GitHub Actions & EventBridge)
The cron expression checker is a free tool that takes a cron expression from crontab, GitHub Actions, Kubernetes CronJob, AWS EventBridge or Spring's @Scheduled, explains what it means in plain words, and lists the next run times in Japan time and UTC. GitHub Actions schedules are read in UTC, so "weekdays at 9:00 Japan time" becomes "0 0 * * 1-5". It automatically handles the case where 0:00–8:59 Japan time falls on the previous day and weekday, splits an expression into two lines when one line is not enough, and even verifies that the run times before and after conversion match. It also warns about pitfalls: specifying both day and weekday means "either", a * in the minute field runs 60 times an hour, */7 is not every 7 minutes, some months never run with day 31, a forgotten ? in EventBridge or a shifted weekday number, and an unescaped % in a crontab command. It comes with a builder that creates an expression just by choosing options, and a cheat sheet of common patterns.
1. Paste a cron expression
You can paste a crontab line, a GitHub Actions YAML line (- cron: '…'), cron(…), or @Scheduled(cron = "…") as is.
Where will you use it?
2. Meaning (translation)
Weekdays (Mon–Fri), at 9:00(Japan time)
| Field | Your value | Meaning |
|---|---|---|
| min | 0 | minute 0 |
| hour | 9 | 9:00 |
| day | * | every day |
| month | * | every month |
| Weekday | 1-5 | Weekdays (Mon–Fri) |
3. Next run times
Run times when this expression is read in Japan time, shown in Japan time and UTC.
Calculating the next run times…
4. Convert to other syntaxes
Rewritten in the syntax of other services so that it runs at the same times. GitHub Actions and EventBridge rules are read in UTC, so the times (and dates and weekdays) are shifted by the time difference.
crontab (Linux)
CRON_TZ=Asia/Tokyo 0 9 * * 1-5 /path/to/command
Open it with crontab -e and write it on one line. CRON_TZ= is cronie syntax (RHEL, Amazon Linux, etc.) and does not work with cron on Ubuntu or Debian, so either set the server time zone (check with timedatectl) to Japan time, or convert the times to the server's time and write those.
GitHub Actions (expression converted to UTC)
on:
schedule:
- cron: '0 0 * * 1-5'
workflow_dispatch:GitHub Actions cron is read in UTC, so the times are shifted by 9 hours from Japan time. Adding workflow_dispatch also lets you run it manually from the Actions page.
Kubernetes CronJob
apiVersion: batch/v1
kind: CronJob
metadata:
name: my-job
spec:
schedule: "0 9 * * 1-5"
timeZone: "Asia/Tokyo"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: job
image: busybox
command: ["sh", "-c", "echo hello"]timeZone is available in Kubernetes 1.27 and later. If you leave it out, the expression is read in the kube-controller-manager time zone (usually UTC).
AWS EventBridge
# EventBridge Scheduler (time zone can be specified)
aws scheduler create-schedule --name my-schedule \
--schedule-expression "cron(0 9 ? * MON-FRI *)" \
--schedule-expression-timezone "Asia/Tokyo" \
--flexible-time-window Mode=OFF \
--target '{"Arn":"arn:aws:lambda:ap-northeast-1:123456789012:function:my-func","RoleArn":"arn:aws:iam::123456789012:role/my-role"}'
# EventBridge rule (read in UTC)
ScheduleExpression: "cron(0 0 ? * MON-FRI *)"EventBridge uses six values: "minute hour day month weekday year", and one of day or weekday must be ?. Weekday numbers start with 1 = Sunday, so names such as MON-FRI are used.
Spring @Scheduled
@Scheduled(cron = "0 0 9 * * MON-FRI", zone = "Asia/Tokyo")
public void run() {
// ...
}Spring has a leading "second" field and uses six values. If you leave out zone, the expression is read in the server (JVM) time zone.
systemd timer (OnCalendar)
[Timer] OnCalendar=Mon..Fri *-*-* 09:00:00 Asia/Tokyo Persistent=true # Check the syntax: systemd-analyze calendar "Mon..Fri *-*-* 09:00:00 Asia/Tokyo"
With Persistent=true, a run that was missed while the machine was powered off is run once at startup (cron has no such feature).
The cron expression and command you enter are only saved in this browser and are never sent to a server. Next run times are calculated from this device's clock.
ABOUT
About cron Expression Checker | Plain-Language Meaning, Next Run Times, Japan Time ⇄ UTC Conversion (GitHub Actions & EventBridge)
The cron expression checker takes a cron expression used in crontab, GitHub Actions, Kubernetes CronJob, AWS EventBridge or Spring's @Scheduled, translates it into plain words such as "weekdays (Mon–Fri) at 9:00", and lists the next 10 run times in Japan time and UTC. GitHub Actions schedules and EventBridge rules are read in UTC, so it subtracts 9 hours from the Japan-time hour and automatically shifts 0:00–8:59 Japan time to the previous day and previous weekday. When one line is not enough it splits the expression into two, and it verifies that the next 40 run times before and after conversion match. It also warns about common mistakes: specifying both day and weekday means "either", a * in the minute field runs 60 times an hour, */7 is not every 7 minutes, some months never run when only day 31 is given, a forgotten ? in EventBridge, and an unescaped % in a crontab command. A builder that creates an expression just by choosing options, rewriting to systemd timer (OnCalendar), and a cheat sheet of common patterns are included.
How to use cron Expression Checker | Plain-Language Meaning, Next Run Times, Japan Time ⇄ UTC Conversion (GitHub Actions & EventBridge)
- 1In "Where will you use it?", choose crontab, GitHub Actions, Kubernetes, EventBridge or Spring
- 2Paste the cron expression (a crontab line, a YAML line like - cron: '…', or cron(…) as is all work)
- 3Check the "Meaning", the explanation for each field, and the list of warnings
- 4In "Next run times", check that the Japan-time and UTC run times, the number of runs in 30 days, and the intervals are what you expect
- 5From "Convert to other syntaxes", copy the GitHub Actions (UTC-converted) expression or the EventBridge, Kubernetes, Spring or systemd syntax
- 6To start from scratch, use "Build a cron expression" and choose every N minutes, weekdays, a day of the month, the last day, or the nth weekday
Great for
- You want a GitHub Actions schedule to run at 9:00 am Japan time but do not know what to write in UTC
- You want to know what Japan time an existing UTC cron in a workflow corresponds to
- You want to confirm when a batch job in a server crontab will next run before putting it into production
- You want to know when an expression with both day and weekday, such as "0 0 13 * 5", actually runs
- You are unsure how to place ? or how weekday numbers work (1 = Sunday) in AWS EventBridge cron(…)
- You want to compare how to run on the last day of the month or on the second Tuesday in crontab, EventBridge and Spring
- You want to copy the same schedule into a Kubernetes CronJob, Spring's @Scheduled or a systemd timer
Good to know
- GitHub Actions schedules are read in UTC in every repository. Japan time (JST) is 9 hours ahead of UTC, so 9:00 Japan time is 0:00 UTC, and 8:00 Monday Japan time is 23:00 Sunday UTC.
- GitHub Actions schedules have a shortest interval of 5 minutes, and during busy times (especially minute 0 of each hour) they can be delayed by several minutes to tens of minutes, or occasionally not run at all. In public repositories, scheduled workflows are automatically disabled after 60 days without repository activity.
- In crontab, if both the day and the weekday are something other than *, it runs on days matching either (as specified in man 5 crontab). However, if one of them starts with * (such as */2), it is treated as "both". Spring's @Scheduled means "both", and EventBridge requires one of them to be ?.
- AWS EventBridge cron has six values, "minute hour day month weekday year", and weekday numbers are 1 = Sunday and 7 = Saturday (in crontab, 0 or 7 is Sunday). L (last day), W (nearest weekday) and # (nth weekday) can be used. Rules are in UTC, while EventBridge Scheduler lets you specify a time zone.
- Next run times are calculated from this device's clock in the selected time zone. In regions with daylight saving time (US, UK), times that do not exist on the switchover day are skipped.
- The cron expression and command you enter are only saved in this browser (localStorage) and are never sent to a server.
Questions this tool answers
Use cron Expression Checker | Plain-Language Meaning, Next Run Times, Japan Time ⇄ UTC Conversion (GitHub Actions & EventBridge) for searches like these:
- How to write a GitHub Actions cron to run at 9 am Japan time
- Translate a cron expression into plain words and check when it runs next
- Find out what Japan time a UTC cron runs at
- What happens when cron has both a day and a weekday
- How to run cron on the last day of the month or the second Monday
- AWS EventBridge cron syntax and the meaning of ?
- crontab syntax for every 5 minutes, weekdays only, or the 1st of every month
- Run a Kubernetes CronJob or Spring's @Scheduled in Japan time
FAQ
- How do I write a GitHub Actions cron to run in Japan time?
- GitHub Actions schedules are read in UTC, so subtract 9 hours from the Japan-time hour. Every day at 9:00 Japan time is "0 0 * * *", and weekdays at 9:00 is "0 0 * * 1-5". Japan time 0:00–8:59 is the previous day in UTC, so for weekdays at 8:30 you also shift the weekday back by one and write "30 23 * * 0-4" (23:30 UTC, Sunday to Thursday). If you enter the Japan-time expression into this tool's "Japan time and UTC conversion", it outputs the shifted expression and the next run times.
- What happens when I specify both the day and the weekday in cron?
- In crontab (Linux cron), GitHub Actions and Kubernetes, if both the day and the weekday are something other than *, it runs on days matching either. For example, "0 0 13 * 5" does not run only on Friday the 13th; it runs on the 13th of every month and on every Friday. To get days that satisfy both, such as the "first Monday", set the day to 1-7 and check the weekday at the start of the command, or use syntax like "MON#1" in EventBridge or Spring.
- What is the difference between "* 9 * * *" and "0 9 * * *"?
- "* 9 * * *" has * in the minute field, so it runs 60 times, once every minute from 9:00 to 9:59. To run just once at 9:00 every day, "0 9 * * *", with the minute set to 0, is correct. This is the most common cron mistake, and the tool shows it as a warning.
- How do I run cron on the last day of every month?
- crontab and GitHub Actions have no syntax for the last day, so set the day to 28-31 and check at the start of the command whether tomorrow is the 1st (example: 0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && command). Note that in crontab, % inside a command must be written as \%. In AWS EventBridge you can use L, as in cron(0 23 L * ? *), and in Spring as in 0 0 23 L * *.
- Does "*/7" mean every 7 minutes?
- No. "*/7" runs at minutes 0, 7, 14, 21, 28, 35, 42, 49 and 56 of every hour, and after 56 comes minute 0 of the next hour, so only that gap is 4 minutes. A number that divides 60 evenly (1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30) keeps the intervals even. The tool's "Interval between runs" shows the shortest and longest intervals.
- What does "?" mean in AWS EventBridge cron?
- "?" means "no specific value", and in EventBridge exactly one of the day (3rd value) or the weekday (5th value) must be ?. Every day is cron(0 9 * * ? *), and weekdays is cron(0 9 ? * MON-FRI *). Writing values in both is an error. Also, EventBridge weekday numbers start with 1 = Sunday, so writing names such as MON-FRI helps avoid mistakes.
- Why doesn't date +%Y%m%d work in a crontab command?
- In crontab, % inside a command is treated as a newline, and everything after the % is passed to standard input. So something like date +%Y%m%d is cut off partway. Inside crontab, write date +\%Y\%m\%d with a \ before each %, or put the date handling into a shell script and call that script from crontab.
Special Thanks