Running GitHub Actions cron on Japan Time: UTC Conversion Table and Fixing Day Shifts and Delays

Why is it 9 hours off? GitHub Actions cron is always UTC

In GitHub Actions, adding on.schedule with a cron expression to a workflow’s YAML lets you run jobs at set times. That cron expression is read as UTC, no matter which country the repository owner lives in or where the runner is. It is never adjusted to Japan time based on your computer’s clock or any repository setting.

Japan Standard Time (JST) is 9 hours ahead of UTC. So 0:00 UTC is 9:00 in Japan, and 9:00 UTC is 18:00 in Japan. If you write “0 9 * * *” thinking in Japan time, it runs at 9:00 UTC, which is 18:00 in Japan. The “it ran at 6 p.m.” story above is exactly this.

• Japan time → UTC: subtract 9 from the hour (9:00 → 0:00, 18:30 → 9:30)
• If the result is negative (Japan time 0:00–8:59), add 24 and treat it as the previous day (8:00 → 23:00 the day before)
• UTC → Japan time: add 9 to the hour. If it reaches 24 or more, subtract 24 and treat it as the next day
• Japan has no daylight saving time, so the offset never changes with the season (always 9 hours)

Japan time → UTC cron expression table

Here are common times, with the cron expression you’d write in Japan time next to the UTC expression you actually need in GitHub Actions. Paste the right-hand column straight into - cron: and the job runs at the Japan time on the left (plus the delays explained later).

The rows to watch are the ones that target 0:00–8:59 Japan time. Moving the time back 9 hours lands on the previous day, so the weekday or date has to move back by one as well, not just the hour. If you only fix the hour and turn “weekdays 8:00” into “0 23 * * 1-5”, it runs at 23:00 UTC Monday to Friday, which is 8:00 Tuesday to Saturday in Japan. The job then skips Monday morning and runs on Saturday morning instead.

“Every 2 hours” is another easy one to miss. Japan’s 0, 2, 4…22 o’clock become 15, 17, 19, 21, 23, 1, 3…13 in UTC, all odd hours, so leaving “*/2” as is puts every run an hour off. You need to rewrite it as “1-23/2”, which means the odd hours in UTC.

0:00–8:59 becomes “the previous day”: how to work out the shift

When converting Japan time to UTC, only the hour decides whether the date changes. From 9:00 onward it stays the same day; from 0:00 to 8:59 it becomes the previous day. Here is how to fix the weekday and day-of-month fields.

1. 1

   Subtract 9 from the hour

   For 8:00, 8 − 9 = −1. If it goes negative, add 24 to get 23 and remember that it shifts to the previous day. If the hour is 9 or more, use the result as is; the date doesn’t move.

2. 2

   Move the weekday field back by one

   If it shifts to the previous day, subtract 1 from the weekday numbers. Monday–Friday (1-5) becomes Sunday–Thursday (0-4), Monday (1) becomes Sunday (0), and Sunday (0) becomes Saturday (6). If the weekday is *, nothing needs changing.

3. 3

   Move the day-of-month field back by one

   If you schedule by date, subtract 1 in the same way: the 15th becomes the 14th. But moving the 1st back gives “the last day of the previous month”, which is the 28th to 31st depending on the month, so it can’t be written exactly in a single cron line.

4. 4

   Check against the next run times

   List about 10 upcoming runs of the converted expression in Japan time and check they match what you meant (runs at 8:00 on Monday mornings, and so on). Mistakes in mental arithmetic show up here.

With a single time you can do this in your head, but once several times, weekdays and dates are combined it quickly gets error-prone. The “Convert Japan time and UTC” tab of the cron expression checker takes a Japan-time expression, outputs the UTC version with weekday and date shifts included, and automatically confirms that the next 40 run times match before and after conversion.

When one line won’t do, split - cron: into two lines

If times before and after 9:00 are mixed, as in “weekdays at 7:00 and 12:00” Japan time, only the 7:00 run moves to the previous day when converted to UTC. Times that shift and times that don’t need different weekday fields, so they can’t be combined into one cron expression.

GitHub Actions lets you list several cron entries under on.schedule, so in a case like this write two lines: “- cron: '0 3 * * 1-5'” and “- cron: '0 22 * * 0-4'”. The workflow runs whenever either one matches. If the job needs to know which one triggered it, github.event.schedule contains the cron string that fired, so you can branch on it with an if condition.

Why schedules run late or don’t run, and what to do

Even with the time correctly converted to UTC, GitHub Actions schedules don’t always fire exactly on time. GitHub’s own documentation says runs can be delayed during periods of high load, and that queued jobs may be dropped when it’s busy. Here are the common causes.

Shifting the minute makes the biggest difference. If the job doesn’t need to run at exactly 9:00, writing “17 0 * * *” (9:17 Japan time) avoids the minute-0 rush and visibly shortens the delay. Conversely, for work that must finish before business hours, schedule it 30 minutes to an hour early to allow for delays.

Check after setting it: manual runs and upcoming run times

With a schedule, you don’t know whether it works until the next time comes around. For daily or weekly workflows, a mistake can go unnoticed for days. Checking these three things before and after you push saves rework.

• Add workflow_dispatch: under on: as well, and run it manually from the Actions tab to confirm the job itself succeeds
• Paste the expression into the cron expression checker with GitHub Actions selected, list the upcoming runs in Japan time, and check the weekdays and times are what you intended
• After the first run, add 9 hours to the time in the run history (UTC) and compare it with the Japan time you expected

If you’re unsure about cron syntax itself (the five fields and symbols like */5), the basics are in how to write crontab, with a cheat sheet. For schedules that are hard to express in GitHub Actions cron alone, such as “second Monday of the month” or “end of the month”, cron’s day-of-month/weekday OR rule and how to write nth weekdays and month-end shows how to check the date in the command. To do the same on AWS, see how to write EventBridge cron expressions.

FAQ

How do I run a GitHub Actions cron at 9:00 Japan time?

GitHub Actions reads cron in UTC, so specify 0:00 UTC, which is 9 hours earlier than Japan time. Every day is “0 0 * * *” and weekdays only is “0 0 * * 1-5”. From 9:00 Japan time onward, neither the date nor the weekday shifts, so subtracting 9 from the hour is all you need.

Can I set the GitHub Actions schedule time zone to Japan time?

The cron expression is read as UTC, so the standard approach is to convert the Japan time to UTC. If you only want dates and times inside the job to be Japan time, set TZ: Asia/Tokyo as an environment variable on the step or job. That affects output such as the date command, not the schedule time.

What happens to the weekday when 8:00 a.m. Japan time is converted to UTC?

8:00 Japan time is 23:00 UTC on the previous day, so the weekday moves back one too. Weekdays (Mon–Fri) at 8:00 become 23:00 Sunday–Thursday in UTC, written “0 23 * * 0-4”. If you only fix the hour and write “0 23 * * 1-5”, it runs on Tuesday to Saturday mornings in Japan.

Why doesn’t my GitHub Actions schedule run on time?

Workflows from all over the world pile up at minute 0 of each hour, so runs can be delayed by minutes or tens of minutes, or skipped entirely when it’s busy. Moving the minute away from 0 (to 17, for example) reduces delays. Also check that the workflow is on the default branch, and that in a public repository the schedule hasn’t been disabled after 60 days without activity.

Can GitHub Actions cron run every minute?

No. The shortest interval for a schedule is 5 minutes. Writing “* * * * *” or “*/1 * * * *” still won’t run more often than every 5 minutes. For minute-by-minute monitoring, use a different mechanism, such as an external monitoring service or cron on an always-on server.