GitHub Actions 手动触发正常，为何定时任务不执行？

2026-11-04数据阿明

先确认触发配置的缩进

0 22 * * * 在未指定时区时表示每天 UTC 22

，对应次日 KST 上午 7 点，时间换算没有问题。先检查代码片段的缩进：schedule 和 workflow_dispatch 都应放在 on 下面。

如果仓库中的文件与贴出的片段完全一致，触发配置的层级就有误；如果只是粘贴时丢失了缩进，还不能确定根因。手动执行正常也不能证明默认分支上的定时配置正确。GitHub 的 schedule 配置说明列出了触发配置的嵌套结构和默认时区规则。

检查默认分支 .github/workflows/run.yml 中的触发部分，确保结构如下，并保留已有的 jobs 配置：

on:
  schedule:
    - cron: '0 22 * * *'
  workflow_dispatch:

直接查看 main 分支上的文件原文，不要只检查本地文件或其他分支。

定时工作流只在默认分支运行，使用该分支的最新提交。修改合并到默认分支后，需要等待下一次计划触发时间，手动运行不能替代这项验证。默认分支要求

不能这样判断。列出工作流和获取单个工作流的 REST API 返回的是工作流元数据，不提供完整的 YAML 触发配置。官方响应示例包含 id、path、state 等字段，没有 schedule 字段。

state: active 表示工作流处于启用状态，不能确认定时事件一定会触发；响应中缺少 schedule 也不能证明定时配置未被识别。工作流 REST API 文档

页面上的时钟图标或“Scheduled”字样同样不应作为唯一判断依据。可以直接查看是否有由 schedule 事件创建的运行记录。

如果已经安装并登录 GitHub CLI，可以运行下面的只读查询，将 OWNER 和 REPO 替换为实际仓库信息：

gh api 'repos/OWNER/REPO/actions/workflows/run.yml/runs?event=schedule&per_page=10'

该接口支持通过 event 筛选运行记录。工作流运行记录 API 文档

如果返回了运行记录，说明定时事件已经创建了运行实例。接下来检查 status、conclusion、作业日志和 if 条件，确认运行是否排队、失败或被跳过。
如果请求成功但列表为空，只能说明本次查询没有返回定时运行记录。不能单凭这一结果确定配置错误，也不能排除历史记录已被清理。
如果返回权限错误或找不到资源，先核对仓库名称、文件名和访问权限。

GitHub 说明，定时事件可能在高负载期间延迟，整点是高负载时段之一；负载足够高时，部分排队作业还可能被丢弃。因此，没有在 22

准时启动，不足以说明配置失效。定时调度限制

如果业务允许，可以将时间调整为非整点，例如：

on:
  schedule:
    - cron: '17 22 * * *'
  workflow_dispatch:

这会将计划时间改为每天 KST 上午 7

，但不能保证解决所有调度问题。如果必须保持上午 7 点，就保留原表达式，并接受实际启动可能延迟的限制。

公共仓库连续 60 天没有仓库活动时，定时工作流会自动停用。如果符合这一情况，应检查工作流是否需要重新启用。题目中查询到的 active 状态不支持直接将“工作流已停用”判定为当前根因。自动停用规则

如果定时工作流关联的 actor 账号被暂停、删除或取消配置，也可能出现工作流仍启用、手动运行正常，但定时运行停止的情况。GitHub 的排障文档建议，确认属于这种情况后，由具有仓库 write 权限的用户提交一次 cron 配置变更，以恢复运行。关联账号排查说明

如果上述检查均无异常，且多个预期调度时间过去后仍无运行记录，应整理默认分支上的完整 YAML、相关提交时间、预期 UTC 触发时间和 API 查询结果，再向 GitHub 支持反馈。现有信息不足以认定是 GitHub 调度故障，也没有依据认为重新手动运行一次就能修复定时触发。