怎样写 GitHub Actions 的 cron 才能按日本时间运行？

GitHub Actions 的 schedule 按 UTC 解读，所以要把日本时间的小时减去 9。日本时间每天 9:00 是“0 0 * * *”，工作日 9:00 是“0 0 * * 1-5”。日本时间 0～8 点在 UTC 中是前一天，所以工作日 8:30 的星期也要往前挪一天，写成“30 23 * * 0-4”（周日至周四的 UTC 23:30）。在本工具的“日本时间与 UTC 转换”中输入日本时间的表达式，就会给出平移后的表达式和下次执行时间。

在 cron 中同时指定日和星期会怎样？

在 crontab（Linux 的 cron）、GitHub Actions、Kubernetes 中，日和星期都不是 * 时，会在满足其一的日子执行。例如“0 0 13 * 5”并不只在 13 日的周五执行，而是每月 13 日和每周五都会执行。想要“第 1 个周一”这种同时满足两者的日子，可以把日写成 1-7 并在命令开头判断星期，或者使用 EventBridge、Spring 的“MON#1”这样的写法。

“* 9 * * *”和“0 9 * * *”有什么区别？

“* 9 * * *”的分钟是 *，所以从 9:00 到 9:59 每分钟执行一次，共 60 次。想每天 9:00 只执行 1 次，应写成把分钟设为 0 的“0 9 * * *”。这是 cron 表达式中最常见的写错之处，本工具会作为注意事项显示。

怎样让 cron 在每月最后一天运行？

crontab 和 GitHub Actions 没有表示最后一天的写法，所以把日写成 28-31，并在命令开头判断“明天是不是 1 号”（例：0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && 命令）。注意在 crontab 中命令里的 % 要写成 \%。AWS EventBridge 可以用 L，如 cron(0 23 L * ? *)，Spring 则如 0 0 23 L * *。

“*/7”是每 7 分钟吗？

不是。“*/7”会在每小时的 0、7、14、21、28、35、42、49、56 分执行，56 分之后是下一个小时的 0 分，所以只有这一处间隔是 4 分钟。能整除 60 的数（1、2、3、4、5、6、10、12、15、20、30）才能保持间隔一致。在本工具的“执行间隔”中可以确认最短和最长间隔。

AWS EventBridge 的 cron 中“?”是什么意思？

“?”表示“不指定”，在 EventBridge 中，日（第 3 个值）和星期（第 5 个值）必须有一个写成 ?。每天是 cron(0 9 * * ? *)，工作日是 cron(0 9 ? * MON-FRI *)。两者都写具体值会报错。另外 EventBridge 的星期数字 1 表示周日，所以像 MON-FRI 这样用英文书写更不容易出错。

为什么 crontab 命令里写 date +%Y%m%d 不能运行？

在 crontab 中，命令里的 % 会被当作换行，% 之后的内容会被送到标准输入。因此 date +%Y%m%d 这样的写法会在中途被截断。在 crontab 中请在 % 前加 \，写成 date +\%Y\%m\%d，或者把生成日期的处理放进 shell 脚本，再由 crontab 调用该脚本。

cron 表达式检查器｜释义、下次执行时间、日本时间与 UTC 转换（支持 GitHub Actions·EventBridge）

cron 表达式检查器是一款免费工具，只需粘贴 crontab、GitHub Actions、Kubernetes CronJob、AWS EventBridge、Spring @Scheduled 的 cron 表达式，就能用文字解释其含义，并以日本时间和 UTC 列出接下来的执行时间。GitHub Actions 的 schedule 按 UTC 解读，所以日本时间的“工作日 9:00”要写成“0 0 * * 1-5”。日本时间 0～8 点会变成前一天、前一个星期几的计算，以及一行写不下时拆成两行的处理都会自动完成，还会核对转换前后的执行时间是否一致。同时提醒各种陷阱：日和星期都写会变成“满足其一”、分钟写 * 会每小时执行 60 次、*/7 并不是每 7 分钟、指定 31 日会有不执行的月份、EventBridge 漏写 ? 或星期数字错位、crontab 命令中忘记转义 % 等。另附通过选择即可生成 cron 表达式的构建器，以及常用写法速查表。

1. 粘贴 cron 表达式

可以直接粘贴 crontab 的一行、GitHub Actions 的 YAML 行（- cron: '…'）、cron(…) 或 @Scheduled(cron = "…")。

用在哪里？

cron 表达式（分时日月星期）

示例：

解读此表达式所用的时区

2. 含义（释义）

工作日（周一至周五）9:00（日本时间）

字段	所写的值	含义
分	0	第 0 分
时	9	9 点
日	*	每个日
月	*	每个月
星期	1-5	工作日（周一至周五）

3. 下次执行时间

按日本时间解读此表达式时的执行时间，以日本时间和 UTC 并列显示。

正在计算下次执行时间…

4. 转换为其他写法

已改写为其他服务的写法，使其在相同时间运行。按 UTC 解读的 GitHub Actions 和 EventBridge 规则，会按时差平移时间（以及日期和星期）。

crontab（Linux）

CRON_TZ=Asia/Tokyo
0 9 * * 1-5 /path/to/command

用 crontab -e 打开，写成一行。CRON_TZ= 是 cronie（RHEL、Amazon Linux 等）的写法，Ubuntu、Debian 的 cron 不支持，所以请把服务器时区（用 timedatectl 查看）设为日本时间，或者把时间换算成服务器时间再写。

GitHub Actions（转换为 UTC 的表达式）

on:
  schedule:
    - cron: '0 0 * * 1-5'
  workflow_dispatch:

GitHub Actions 的 cron 按 UTC 解读，所以已从日本时间偏移 9 小时。再加上 workflow_dispatch，还可以在 Actions 页面手动运行。

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 需要 Kubernetes 1.27 及以上版本。不写的话，会按 kube-controller-manager 的时区（多为 UTC）解读。

AWS EventBridge

# EventBridge Scheduler（可指定时区）
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 规则（按 UTC 解读）
ScheduleExpression: "cron(0 0 ? * MON-FRI *)"

EventBridge 由“分时日月星期年”6 个值组成，日或星期中必须有一个写成 ?。星期的数字 1 表示周日，所以这里用 MON-FRI 这样的英文写法。

Spring @Scheduled

@Scheduled(cron = "0 0 9 * * MON-FRI", zone = "Asia/Tokyo")
public void run() {
    // ...
}

Spring 开头有“秒”，共 6 个值。不写 zone 的话，会按服务器（JVM）的时区解读。

systemd timer（OnCalendar）

[Timer]
OnCalendar=Mon..Fri *-*-* 09:00:00 Asia/Tokyo
Persistent=true

# 检查写法：systemd-analyze calendar "Mon..Fri *-*-* 09:00:00 Asia/Tokyo"

设置 Persistent=true 后，因关机而错过的执行会在开机时补跑一次（cron 没有这个功能）。

输入的 cron 表达式和命令仅保存在此浏览器中，不会发送到服务器。下次执行时间是根据本设备的时钟计算的。

ABOUT

关于cron 表达式检查器｜释义、下次执行时间、日本时间与 UTC 转换（支持 GitHub Actions·EventBridge）

cron 表达式检查器只需粘贴 crontab、GitHub Actions、Kubernetes CronJob、AWS EventBridge、Spring @Scheduled 所用的 cron 表达式，就能将其翻译成“工作日（周一至周五）9:00”这样的文字说明，并以日本时间和 UTC 列出接下来的 10 次执行时间。GitHub Actions 的 schedule 和 EventBridge 的规则按 UTC 解读，所以会把日本时间的小时减去 9，并自动把日本时间 0～8 点平移为前一天、前一个星期几。一行写不下时会拆成两行，并确认转换前后接下来 40 次的执行时间是否一致。同时提醒常见的写法错误：日和星期都写会变成“满足其一”、分钟写 * 会每小时执行 60 次、*/7 并不是每 7 分钟、只指定 31 日会有不执行的月份、EventBridge 漏写 ?、crontab 命令中忘记转义 % 等。另有通过选择即可生成表达式的构建器、改写为 systemd timer（OnCalendar）的功能，以及常用写法速查表。

cron 表达式检查器｜释义、下次执行时间、日本时间与 UTC 转换（支持 GitHub Actions·EventBridge）的使用方法

1在“用在哪里？”中选择 crontab、GitHub Actions、Kubernetes、EventBridge、Spring 之一
2粘贴 cron 表达式（crontab 的一行、YAML 的 - cron: '…' 行、cron(…) 原样粘贴均可）
3查看“含义（释义）”、各字段的说明和注意事项列表
4在“下次执行时间”中，确认日本时间与 UTC 的执行时间、30 天内的执行次数和间隔是否符合预期
5在“转换为其他写法”中，复制 GitHub Actions（转换为 UTC 的表达式）或 EventBridge·Kubernetes·Spring·systemd 的写法
6想从零开始生成表达式时，使用“生成 cron 表达式”，选择每 N 分钟、星期、每月某日、最后一天、第 n 个星期几

适用场景

想让 GitHub Actions 的 schedule 在日本时间早上 9 点运行，但不知道 UTC 该怎么写
想知道现有工作流里写的 UTC cron 对应日本时间几点运行
想在上线前确认服务器 crontab 中的批处理下次什么时候运行
想知道像“0 0 13 * 5”这样同时写了日和星期的表达式究竟何时运行
不清楚 AWS EventBridge cron(…) 中 ? 的写法和星期数字（1 是周日）
想对比在 crontab 与 EventBridge·Spring 中每月最后一天或第 2 个周二运行的写法
想把同一个计划写到 Kubernetes CronJob、Spring 的 @Scheduled 或 systemd timer 中

使用要点

GitHub Actions 的 schedule 在任何仓库中都按 UTC 解读。日本时间（JST）比 UTC 快 9 小时，所以日本时间 9:00 是 UTC 0:00，日本时间周一 8:00 是 UTC 周日 23:00。
GitHub Actions 的 schedule 最短为每 5 分钟，在繁忙时段（尤其是每小时 0 分）可能延迟几分钟到几十分钟，偶尔也不会执行。在公开仓库中，若 60 天内仓库没有任何活动，定时工作流会被自动停用。
在 crontab 中，日和星期都不是 * 时，会在满足其一的日子执行（man 5 crontab 的规定）。但如果其中一个以 * 开头（如 */2），则按“两者都满足”处理。Spring 的 @Scheduled 是“两者都满足”，EventBridge 则必须把其中一个写成 ?。
AWS EventBridge 的 cron 由“分时日月星期年”6 个值组成，星期数字 1 是周日、7 是周六（crontab 中 0 或 7 是周日）。可以使用 L（最后一天）、W（最近的工作日）、#（第 n 个星期几）。规则按 UTC，EventBridge Scheduler 可以指定时区。
下次执行时间是根据本设备的时钟，在所选时区下计算的。在有夏令时的地区（美国、英国），切换当天不存在的时间会被跳过。
输入的 cron 表达式和命令只保存在此浏览器（localStorage）中，不会发送到服务器。

可以解决这些问题

cron 表达式检查器｜释义、下次执行时间、日本时间与 UTC 转换（支持 GitHub Actions·EventBridge）可以帮你解决以下问题。

GitHub Actions 的 cron 怎么写才能在日本时间早上 9 点运行
把 cron 表达式翻译成文字，确认下次什么时候运行
想知道 UTC 写的 cron 在日本时间几点运行
cron 同时写日和星期会怎样
cron 在每月最后一天或第 2 个周一运行的写法
AWS EventBridge 的 cron 表达式写法和 ? 的含义
crontab 每 5 分钟、仅工作日、每月 1 日的写法
想让 Kubernetes CronJob 或 Spring 的 @Scheduled 按日本时间运行

常见问题

怎样写 GitHub Actions 的 cron 才能按日本时间运行？: GitHub Actions 的 schedule 按 UTC 解读，所以要把日本时间的小时减去 9。日本时间每天 9:00 是“0 0 * * *”，工作日 9:00 是“0 0 * * 1-5”。日本时间 0～8 点在 UTC 中是前一天，所以工作日 8:30 的星期也要往前挪一天，写成“30 23 * * 0-4”（周日至周四的 UTC 23:30）。在本工具的“日本时间与 UTC 转换”中输入日本时间的表达式，就会给出平移后的表达式和下次执行时间。
在 cron 中同时指定日和星期会怎样？: 在 crontab（Linux 的 cron）、GitHub Actions、Kubernetes 中，日和星期都不是 * 时，会在满足其一的日子执行。例如“0 0 13 * 5”并不只在 13 日的周五执行，而是每月 13 日和每周五都会执行。想要“第 1 个周一”这种同时满足两者的日子，可以把日写成 1-7 并在命令开头判断星期，或者使用 EventBridge、Spring 的“MON#1”这样的写法。
“* 9 * * *”和“0 9 * * *”有什么区别？: “* 9 * * *”的分钟是 *，所以从 9:00 到 9:59 每分钟执行一次，共 60 次。想每天 9:00 只执行 1 次，应写成把分钟设为 0 的“0 9 * * *”。这是 cron 表达式中最常见的写错之处，本工具会作为注意事项显示。
怎样让 cron 在每月最后一天运行？: crontab 和 GitHub Actions 没有表示最后一天的写法，所以把日写成 28-31，并在命令开头判断“明天是不是 1 号”（例：0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && 命令）。注意在 crontab 中命令里的 % 要写成 \%。AWS EventBridge 可以用 L，如 cron(0 23 L * ? *)，Spring 则如 0 0 23 L * *。
“*/7”是每 7 分钟吗？: 不是。“*/7”会在每小时的 0、7、14、21、28、35、42、49、56 分执行，56 分之后是下一个小时的 0 分，所以只有这一处间隔是 4 分钟。能整除 60 的数（1、2、3、4、5、6、10、12、15、20、30）才能保持间隔一致。在本工具的“执行间隔”中可以确认最短和最长间隔。
AWS EventBridge 的 cron 中“?”是什么意思？: “?”表示“不指定”，在 EventBridge 中，日（第 3 个值）和星期（第 5 个值）必须有一个写成 ?。每天是 cron(0 9 * * ? *)，工作日是 cron(0 9 ? * MON-FRI *)。两者都写具体值会报错。另外 EventBridge 的星期数字 1 表示周日，所以像 MON-FRI 这样用英文书写更不容易出错。
为什么 crontab 命令里写 date +%Y%m%d 不能运行？: 在 crontab 中，命令里的 % 会被当作换行，% 之后的内容会被送到标准输入。因此 date +%Y%m%d 这样的写法会在中途被截断。在 crontab 中请在 % 前加 \，写成 date +\%Y\%m\%d，或者把生成日期的处理放进 shell 脚本，再由 crontab 调用该脚本。

Special Thanks

SOLO GUILD | サービス作るAIエンジニア

返回工具列表