Upptime：把 GitHub Actions 变成免费且自托管的 uptime 监控与状态页
GitHub Actions 正常运行时间监视器和状态页面，作者：@AnandChowdhary。 Upptime**（是开源的正常运行时间监视器和状态页面，完全由 GitHub 操作、问题和页面提供支持，由 Anand Chowdhary 制作。
秒懂
- 它是什么？
- Upptime 用 GitHub Actions 做定时探测，用 Issues 记录故障，用 Pages 生成状态页。它把监控基础设施压缩进一个 GitHub 仓库，适合已经深度使用 GitHub 的团队，但它的运行方式和数据存储也带来一些必须接受的边界。
- 适合谁用？
- Upptime 适合已经以 GitHub 为日常工具、愿意把监控数据放进公开或私有仓库的个人开发者和小型团队，尤其是想省掉外部监控服务订阅成本的人。它不适合需要秒级告警、自定义通知渠道、或必须将监控数据与代码仓库解耦的企业环境。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Markdown（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的问题：把监控塞进一个 GitHub 仓库
Upptime 瞄准的是一个很具体的痛点：个人开发者或小团队想要 uptime 监控和状态页，但不想为此租服务器、买订阅，也不想把服务状态数据交给第三方闭源平台。作者 Anand Chowdhary 在 README 里说，他做这个项目是因为自己需要一个便宜、灵活、完全可控的监控方案。Upptime 的做法是把整个监控系统折叠进一个 GitHub 仓库：GitHub Actions 负责定时探测，GitHub Issues 负责故障事件，GitHub Pages 负责展示状态页。你不需要额外的域名、服务器或数据库，只要有一个 GitHub 账号，就能得到一个完整的监控链路。这个设计对已经活在 GitHub 生态里的人非常自然，但对不熟悉 GitHub 的人来说，学习曲线会比传统 SaaS 监控陡峭一些。
运行机制：三个 GitHub 服务如何拼成监控系统
Upptime 的核心是几个 GitHub Actions workflow，它们在仓库里定时运行。根据 README 的描述，一个 workflow 每 5 分钟访问一次你的网站，检查是否在线。另一个 workflow 记录响应时间，并把数据提交到 git 历史里，这样就能生成长期趋势图。当探测到宕机时，GitHub Issues 会被自动创建，恢复后自动关闭。状态页本身是一个用 Svelte 构建的静态站点，托管在 GitHub Pages 上，显示 uptime 百分比、响应时间和故障历史。整个系统的数据流是：探测结果写入 git 提交，然后其他 workflow 读取这些提交来生成图表和页面。这意味着每一次探测、每一次状态变化都成为仓库里的一次提交，形成一个天然的审计日志。这个设计很聪明，但也意味着监控历史完全依赖仓库的完整性，一旦删除仓库，所有数据随之消失，README 里也明确说了这一点。
配置方式：一个文件搞定，但细节藏在模板里
Upptime 的配置集中在单个文件里，README 强调所有配置都在一个文件中。实际使用方式是 fork 官方仓库或者用模板仓库创建一个新仓库，然后在配置文件中列出你要监控的 URL。官方 demo 显示，每个被监控的站点会生成一个 YAML 文件，例如 google.yml、wikipedia.yml，这些文件记录该站点的状态历史和响应时间。配置项包括监控频率，官方说明是“as often as every 5 minutes”，也就是说你可以把间隔调短，但更短的间隔会消耗更多 GitHub Actions 分钟数。工作流的配置分散在 .github/workflows 目录下，包含 uptime.yml、response-time.yml、graphs.yml、site.yml、summary.yml 等。如果你只想快速跑起来，fork 模板然后改配置文件即可；但如果你想调整探测逻辑或通知方式，你需要直接修改这些 workflow 文件，这要求你理解 GitHub Actions 的语法。
真正的限制：GitHub 配额、公开数据与探测盲区
Upptime 的免费属性建立在 GitHub 的免费配额之上，这是它的优势，也是它的天花板。GitHub Actions 对免费账号有每月分钟数限制，每 5 分钟探测一次，一天就有 288 次运行，一个月接近 8640 次，会迅速消耗配额。如果你监控多个端点，配额消耗会成倍增加。更关键的是，GitHub Pages 默认是公开的，意味着你的状态页、响应时间、故障历史对任何人都可见。虽然你可以把仓库设为私有，但私有仓库的 Actions 分钟数更少，而且 Pages 在某些方案下需要付费。另一个问题是探测来源：请求来自 GitHub 托管的运行器，其 IP 段可能被某些站点屏蔽，导致误报。Upptime 的 README 没有讨论这个问题，但这是任何基于云运行器的监控方案都会遇到的现实。如果你监控的是内网服务或需要认证的端点，Upptime 基本无能为力，因为它只做简单的 HTTP 探测。
维护与升级成本：git 原生，但依赖 GitHub 的变动
Upptime 的维护成本有两个层面。第一，数据维护：所有历史都存储在 git 提交中，这意味着仓库会随时间膨胀，尤其是响应时间数据频繁提交时。你需要偶尔清理历史或接受仓库体积增长。第二，依赖维护：Upptime 依赖 GitHub Actions 的调度稳定性、Issues API 的可用性、Pages 的部署机制。GitHub 任何一项服务的策略调整都会直接影响 Upptime 的运行。项目本身采用 MIT 许可证，你可以自由修改和分发，但如果你 fork 后做深度定制，你需要自己跟上上游的更新。从版本历史看，v2.0.0 在 2020 年 10 月发布，之后没有活跃的 release，说明项目维护节奏可能放缓。这意味着新用户可能遇到未修复的 bug，或者 GitHub 更新后出现兼容问题。
替代方案：从自托管到 SaaS 的三种不同思路
Upptime 的核心创新是零服务器监控，但这不是唯一路径。如果你愿意自托管，Uptime Kuma 是另一个开源选择，它需要你运行一个 Node.js 服务，提供 Web 界面和多种通知渠道，比如 Telegram、Discord 和邮件。它的数据存在本地 SQLite 中，不依赖任何第三方平台。与 Upptime 相比，Uptime Kuma 更传统，但你需要自己维护服务器。如果你想要商业 SaaS 的省心，UptimeRobot 提供免费层级，支持多种监控类型和通知方式，但你的数据在别人手里。Upptime 与这两者的本质区别在于它把监控基础设施完全建立在 GitHub 之上，而不是自己的服务器或别人的 SaaS。这意味着它的运维成本最低，但灵活性也最差。如果你需要自定义监控逻辑，比如检查页面关键字或模拟登录，Upptime 的 workflow 可以改，但改起来比 Uptime Kuma 的插件机制更繁琐。
谁适合用，谁应该绕开
Upptime 适合那些已经把所有东西都放进 GitHub 的开发者，尤其是个人项目或开源项目，想要一个免费、公开的状态页，并且不介意监控数据以 git 提交的形式存在。它非常适合展示给用户看，因为状态页是静态的，加载快，而且故障历史天然可追溯。但它不适合需要主动告警的团队，因为 GitHub Issues 的通知机制不如专门的告警系统及时，而且没有电话或短信通知。也不适合监控大量端点或需要高频探测的场景，因为 Actions 配额会很快耗尽。如果你监控的是内部服务或需要验证内容正确性，Upptime 的简单 ping 不够用。最终判断：Upptime 是一个聪明的、把平台能力用到极致的工具，但它的适用边界非常清晰，超出边界就会变成负担。
编辑结论
Upptime 适合已经以 GitHub 为日常工具、愿意把监控数据放进公开或私有仓库的个人开发者和小型团队，尤其是想省掉外部监控服务订阅成本的人。它不适合需要秒级告警、自定义通知渠道、或必须将监控数据与代码仓库解耦的企业环境。在采用之前，先确认你的 GitHub Actions 配额足够支撑每 5 分钟一次的探测频率，并明确你的仓库隐私设置：公开仓库意味着所有响应时间和故障历史对任何人可见。还要验证你的目标端点是否接受来自 GitHub 托管运行器的请求，有些站点会拦截云 IP 段，这会导致误报。最后，确认你能接受数据随仓库删除而消失，且没有导出机制。
社区笔记