Agent Skills
返回列表
🔒

Upptime 网站监控状态页

IT 运维与安全 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/upptime-github-actions-uptime-monitor-status-page 技能到你的 AI 助手中。

技能介绍

要解决的问题

多数团队的网站监控只有两个选择：要么买商业 SaaS 监控服务，要么自己搭 Zabbix、Prometheus 之类的监控服务器。前者要按用量付费、告警规则受限于供应商；后者要维护服务器、数据库和告警通道，对小团队来说明显过度设计。Upptime 的思路是：如果你已经在用 GitHub，那 GitHub Actions、Issues 和 Pages 本身就能拼出一套监控和状态页，没必要再跑一套独立基础设施。

这个技能围绕 Upptime 展开，定位是一个 ASE（Agent Skill Environment）技能，帮助 agent 快速理解并使用这套基于 GitHub 的开源监控系统。

它如何工作

Upptime 的核心机制是用 GitHub Actions 定时执行 HTTP 探测：

  • 你在仓库的配置文件里写入要监控的 URL 列表
  • 定时 workflow 对每个 URL 发起请求，记录响应状态和耗时
  • 站点宕机时，workflow 自动创建一个 GitHub Issue（例如 issue #67），作为事件工单
  • 你可以在该 issue 下补充 incident report，记录故障原因和修复进度
  • 仓库通过 GitHub Pages 自动生成公开或内部的状态页面，展示历史运行时间和可用率

对 agent 来说，这个技能的价值在于：监控、事件跟踪、状态页这三件事不再需要部署和运维任何服务器，只需要一个 GitHub 仓库。CSstricks 的评价是「极其聪明地使用了 GitHub Actions，相当于免费得到一个可配置的、针对任何目标的 uptime monitor」。

适用边界

  • 依赖 GitHub 生态：需要仓库、Actions、Issues、Pages 全部可用，私有化部署或离线环境不适用
  • 探测频率受 GitHub Actions 配额限制，不适合需要秒级监控的高要求场景
  • 监控节点本身托管在 GitHub 上，属于「同源监控」，极端情况下 GitHub 故障时监控和告警也会一起不可用
  • 适合中小型站点、API 端点、内部服务的状态公示；金融级 SLA 场景仍需专业监控方案

文档地址：https://upptime.js.org

使用场景

  • 个人开发者上线了个人博客和 API，想零成本监控这两个端点的可用性，站点挂掉时自动生成记录问题的 Issue。
  • 开源项目维护者希望为项目官网和 API 提供公开状态页，向用户展示历史运行时间和可用率趋势。
  • 几人小团队没有专职运维，希望故障发生时自动创建 Issue，并在其中补充处理过程、跟踪修复进度。
  • 内部平台团队想为公司内部服务建立状态页，让同事随时查看各系统当前的运行状态。

适合人员

  • 独立开发者：上线了个人站点或 API，需要免费、免运维的可用性监控方案。
  • 开源项目维护者：希望为项目官网和 API 提供公开状态页，向用户公示运行状况。
  • 小团队技术负责人：团队没有专职运维，想用 GitHub Issues 跟踪宕机事件的处理过程。
  • 内部平台工程师：需要为公司内部服务搭建轻量状态页，不想维护独立监控服务器。