GitHub Git与PR事件已恢复：Actions延迟时间线及工作流补跑检查

GitHub已确认，2026年11月10日发生的Git操作与Pull Requests事件恢复，恢复公告对应北京时间11月11日01:55。事件期间Git操作和PR响应变慢，部分PR处理延迟或失败，PR触发的Actions工作流也曾延迟。服务恢复后，团队仍应核对各仓库运行记录，再补跑确实失败或未完成的任务。

这次GitHub事件影响了哪些环节

状态页最初记录Actions与Pull Requests性能下降，后续说明涉及Git操作及PR响应时间升高，并明确指出由Pull Requests触发的GitHub Actions工作流延迟。这会影响依赖PR处理、检查结果及持续集成反馈的开发流程，但公告没有证明所有仓库、所有工作流或所有Git请求都失败。

对使用者来说，看到PR检查长时间没有更新、工作流启动较慢，可能与平台事件有关；但单个任务的失败也可能来自项目自身的构建、权限或依赖问题。建议把实际任务时间、提交及工作流日志与官方事件进展对照，而不是把所有报错都归为同一个原因。

按北京时间还原官方进展

11月11日00:10，GitHub开始记录对Actions和Pull Requests性能下降的调查；00:26表示这两个组件的可用性下降。00:31的说明进一步确认，Git操作与PR响应时间升高，PR触发的Actions工作流延迟。00:39又单独报告Actions可用性下降。

01:07的更新称部分PR处理和Actions工作流有所改善，但仍有延迟与失败；01:12仍标记PR性能下降。01:28发布过Actions正常运行的更新，01:46又说明工作流正在恢复，而PR处理仍存在延迟和失败。最后在01:55，整个事件被标记为Resolved。

以上是状态公告发布时间，不是对每一个请求的故障起止测量。组件更新与整个事件关闭属于不同层次，不能仅用其中一个时间点就认定所有仓库积压都已处理完毕，也不能把最初调查时间当作精确故障开始时刻。

先检查PR、提交与Actions记录

建议先确认需要处理的PR对应哪个提交，查看检查结果是否属于预期提交，再进入仓库Actions标签页，选择相关工作流及具体运行。GitHub文档说明，运行日志包含各个job和step的状态，查看这些记录需要仓库读取权限。这样可以区分任务仍在等待、已经成功，还是确实失败并需要处理。

使用GitHub CLI时，可用gh run list --limit 5查看近期运行，也可通过gh run view RUN_ID查看指定运行；加--verbose可查看步骤信息，--log可读取日志。这里的RUN_ID应替换为自己仓库中实际的运行标识，不能使用事件页编号代替工作流运行编号。

确实需要重跑时，有哪些限制

GitHub支持重跑整个工作流、所有失败job或指定job。按当前文档，重跑窗口为首次运行后的30天内，需要仓库写权限；工作流被禁用时不能直接重跑。每次运行最多可重跑50次，这一限制同时包含完整重跑和部分job重跑。

重跑会使用最初触发者的权限，并沿用原事件的GITHUB_SHA与GITHUB_REF，而不是自动改为当前分支最新内容。因此，如果目标是验证一份新提交，不能把旧运行重跑后成功直接当作新提交已通过。重跑失败或指定job时，其依赖job也会重跑，未包含的job保留上次输出供新的尝试使用。

网页端可从运行摘要右上角的Re-run jobs选择重跑全部或失败job；命令行可使用gh run rerun RUN_ID，并用gh run watch观察进度。建议在确认已有发布、部署或外部操作结果后再选重跑范围，避免把平台恢复后的补偿动作变成重复执行。本文没有替用户运行这些命令。

恢复公告没有说明的内容

恢复记录表示会在可用时分享详细根因分析，但当前事件页没有给出完整根因。不能据此宣称源代码丢失、仓库数据损坏、攻击或某个具体基础设施故障。页面确认的是所列服务事件已解决，项目侧仍须依靠自身日志、提交和任务结果完成验收。

只看到Actions正常，是否可以忽略PR检查？

不宜。该事件中Actions组件曾先给出正常更新，而后续记录仍提到PR处理延迟和失败。对合并或交付流程，应分别确认PR状态、目标提交的检查结果和工作流最终结果，不能用一个组件的恢复说明替代仓库级核对。