你的 GitHub Actions 工作流可能已经失败好几周了

无人察觉的隐患

你的 GitHub Actions 工作流可能已经默默失败了好几周。你却一无所知。它只是静悄悄地显示为红色，明天再次运行，再次失败，由于没有人在关注，也就没有人会注意到。

这绝非耸人听闻。在 2026 年 6 月 30 日，这种情况随处可见。被成千上万开发者使用的库 trpc，包含一个名为 "Lock Issues PRs" 的定时工作流，它几乎每次运行都会失败——并且已经持续很长时间了。查看它的评分卡，你会看到一片红。但该项目依然在不断交付优秀的软件。Drizzle ORM 也有一个类似的工作流，名为 "Unpublish release"。cal.com 同样如此。我在 35 个热门开源项目中发现了相同的现象：定时工作流默默地失败，几乎每次都如此，且已持续数月。为什么会这样？更重要的是——你的项目是否也是如此？

为什么 GitHub Actions 工作流在当下至关重要

GitHub Actions 已经成为绝大多数开源项目和许多公司事实上的自动化标准工具。如果你将代码推送至 GitHub，你几乎必然会使用 Actions 来运行测试、构建 Docker 镜像、部署到生产环境或检查代码质量。现代团队正是通过 Actions 来避免繁琐的手动工作，并在 Bug 影响用户之前将其捕获。

但 Actions 工作流只有在正常工作时才有价值。一个不断失败的工作流就像失灵的警报——它要么频繁发出误报，让你习惯性地忽略它，要么根本不发出警报，导致你错过真正的问题。

工作流如何演变为无人察觉的灾难

大多数 GitHub Actions 工作流是按计划运行的——例如每天晚上、每周，或通过 cron 定时器触发。这些正是极易出问题且无人察觉的典型对象。工作流运行并失败了，GitHub 发送了通知——但如果你没有时刻关注，或者通知被发送到了无人查看的团队邮箱，这次失败就会悄无声息地消失在数字黑洞中。

这些工作流频繁失败的真实原因往往非常平凡。外部 API 发生了变更；依赖项发布了破坏性更新；权限配置错误；Docker 镜像仓库宕机；SSH 密钥过期。一个工作流在前六个月运行完美，接着外界发生了变化，却没有人同步更新这个工作流——直到有一天你翻看日志，才发现它已经飘红好几周了。

由于这些工作流通常脱离于常规开发流程之外——它们不由 Pull Request 触发，只是按定时器运行——因此很容易被遗忘。日常的构建？你立刻就能注意到。而一个在凌晨 2 点运行的定时任务？你可能要在几个月后偶然间才会发现它早已出问题。

如何找出你项目中失败的工作流

步骤 1：访问你的 GitHub 仓库

打开在 github.com 上的仓库，找到页面顶部附近的 "Actions" 标签页。点击进入，你将看到所有工作流的列表。

步骤 2：寻找红色状态

浏览工作流列表。任何标记有红色 X 或 "failed" 徽章的工作流都代表它一直在失败。点击它可以查看完整历史记录。

步骤 3：检查运行历史

点击某个工作流后，GitHub 会展示其历次运行记录。如果近期运行记录中红色多于绿色，说明该工作流已损坏。红色记录越久远，意味着它在无人察觉的情况下损坏的时间越长。

步骤 4：查看错误日志

点击任意失败的运行记录，了解具体出了什么问题。错误信息会告诉你这是网络问题、权限问题、损坏的依赖项，还是其他原因造成的。

步骤 5：修复或禁用

你有两种选择：修复底层问题（更新出问题的依赖项、刷新过期的凭据、调整适应新端点的 API 调用），或者如果不再需要该工作流，直接将其禁用。你可以通过删除或注释掉 schedule 触发器，或者在 Actions 标签页中点击 "Disable workflow" 来禁用工作流。

为什么工作流失败容易被忽视

主要原因有三点。

首先，定时工作流失败时不会高调示警。它们不会阻碍 Pull Request，不会停止部署，也不会出现在任何人的每日站会中。它们只是在后台静悄悄地运行并悄无声息地飘红。

其次，GitHub 通知很容易被无视。如果你的团队将工作流通知发送到 Slack 频道或邮件组，它们很快就会淹没在信息洪流中。在收到第二十条 "workflow failed" 通知后，你的大脑就会停止对其做出反应。

第三——这也许才是根本原因——我们大多数人默认自己的工作流一切正常。如果我们推送了代码且工作流通过了，就会认为它是健康的。我们不会主动去检查在我们睡觉时运行的定时任务是否依然正常运作。在你主动查看之前，它仿佛是不存在的。

现在应该做些什么

打开你最重要的三个 GitHub 仓库。进入每个仓库的 Actions 标签页。排查红色的失败记录。如果你发现某个失败的工作流已经飘红超过一周，请阅读错误日志。如果找到了原因，就修复它。如果该工作流已成废弃代码且无人需要，就删掉它。无论哪种方式，你都成功避免了未来因该工作流静默失效而引发重要隐患的可能。

然后设置一个日历提醒，每月检查一次工作流。花三分钟看看颜色标记的列表，就能避免六个月后花费数小时去排查某种莫名其妙的失败。

结语

GitHub Actions 工作流失败非常常见，但它们不必一直处于损坏状态。几分钟的排查和快速修复，就能将一场隐蔽的灾难转变为可靠的自动化工具。今天就去检查一下你的仓库吧。

优点

• 能捕获数月来默默失败的工作流
• 只需几分钟即可完成排查与修复
• 预防因自动化损坏引起的未来故障
• 提升团队对 CI/CD 系统的信任度
• 促使团队建立更好的监控习惯

缺点

• 需要手动排查——GitHub 默认不会对旧的失败发出特别警报
• 容易忘记检查；需要养成定期排查的习惯
• 部分工作流如果在缺乏深层上下文的情况下可能较为复杂、难以调试
• 修复损坏的工作流可能会暴露深层的基础设施问题
• 并非所有团队都有足够的资源维护每一个定时任务

注意事项

本文使用了通用示例和占位符名称（trpc、drizzle-orm、cal.com 是真实的开源项目，但相关细节仅作说明之用）。在检查你自己的工作流时，请仔细阅读错误信息，并在假定修复方案可安全用于生产环境之前，先在测试或预发环境中验证其有效性。如果工作流涉及部署、数据库变更或凭据轮换，请谨慎行事并进行充分测试。你需要为你自己自动化的可靠性与安全性负责。

常见问题

• 如何知道我的 GitHub Actions 工作流是否已经失败了很久？
• GitHub Actions 工作流失败的最常见原因是什么？
• 如何禁用 GitHub Actions 工作流？
• GitHub 能否就工作流失败向我发送警报？
• 我应该删除旧的工作流还是修复它们？
• 如何在推送之前在本地测试 GitHub Actions 工作流？
• 什么是定时工作流，为什么它们会静默失败？
• 我应该多久检查一次 GitHub Actions 工作流的失败情况？

标签

#github #githubactions #cicd #devops #automation #monitoring #bestpractices #workflows