# 【开源自荐】为了确认是网络挂了还是网站崩了，我做了一个服务监控站 PongHub **URL:** \ **Category:** 发现频道\ **Tags:** chrome\ **Created:** [2025 年7 月 24 日 15:38 UTC](https://meta.appinn.net/t/topic/73616 "2025-07-24T15:38:56Z")\ **Posts on this page:** 14\ **Page:** 1
作者： ![ch3nyang](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ch3nyang/32/68581_2.png) [@ch3nyang](https://meta.appinn.net/u/ch3nyang)\ 发布日期： [2025 年7 月 24 日 15:38 UTC](https://meta.appinn.net/t/topic/73616/1 "2025-07-24T15:38:56Z")
# 软件名称 PongHub # 应用平台 简单修改配置文件后即可一键部署到 GitHub Pages 上 ## 一句简介 一个 **开源** 、 **0侵入性** 且足够 **易用** 的 **服务状态监控** 网站，旨在帮助用户监控和验证服务的可用性。 # 应用简介 ![browser_CN.png](https://h1.appinn.me/file/1753367581916_browser_CN.png) ## 为什么做这个工具？ 相信不少人有这样的烦恼： 1. 推特崩了，刷新不出来，还以为是自己那个_神秘网络工具_的问题 2. 自己搭建的网站崩了，结果过了好几天有用户提醒才发现 现有的解决方案有两类： 1. 以 prometheus 为首的工具，通过在服务器内部安装该工具，可以实现对服务器的监控——但它_必须修改服务器代码_ 2. uptimerobot、OpenStatus 等网站，它们功能繁多，且无需修改服务器——但使用_不是那么方便，而且收费_ 于是，我就想到了可以仿照后者，但是白嫖 GitHub Actions 的免费资源，再通过 GitHub Pages 发布，最终得到了 PongHub！ ## 为什么向大家推荐这个工具？ 目前，PongHub 主要有这么几个优点： - **🕵 零侵入监控** - 无需改动服务器即可实现全功能监控 - **:rocket: 一键免费部署** - 通过 Actions 自动构建，一键部署至 Github Pages - **🌐 全平台支持** - 兼容 OpenAI 等公共服务及私有服务接口 - **🔍 多端口探测** - 单服务支持同时监控多个端口状态 - **:robot: 智能响应验证** - 精准匹配状态码及正则表达式校验响应体 - **🛠 自定义请求引擎** - 自由配置请求头/体、超时和重试策略 ## 真的好用吗？ 使用 PongHub 分为两步： 1. Fork 走这个仓库 2. 修改下 `config.yaml` 然后网站就建好了，再也不用管它了。 # 备注 写这个工具也就花了我两个晚上，它已经能满足我自己所有需求了。但如果要当作一个产品来做，我还没想好开发路线。 诚挚邀请大家提一提自己的需求和建议！ # 网址 > **[GitHub - WCY-dt/ponghub: Free endpoint monitoring. One-click deployment.](https://github.com/WCY-dt/ponghub)** > > Free endpoint monitoring. One-click deployment. 不管是否愿意帮忙点个 Star，我都先感谢您看到这里 :smiling_face_with_three_hearts:！ # 更新 - **07-27** - 新增响应时间的检测和历史记录 - 如果有端口不可用，将会通过 GitHub Actions 自动报错通知用户 ---
作者： ![tjsky](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/tjsky/32/31059_2.png) [@tjsky](https://meta.appinn.net/u/tjsky)\ 发布日期： [2025 年7 月 24 日 16:12 UTC](https://meta.appinn.net/t/topic/73616/2 "2025-07-24T16:12:41Z")
基于我使用另一个基于action的监控工具（[upptime](https://github.com/upptime/upptime)）的经验看， 最大的问题就是 github action的 cron 并不是准时的，而是根据资源情况执行的。 所以即使设置 crom 是\*/30，甚至\*/15，也有可能两次执行的间隔能错开一个多小时。 导致监控粒度非常稀疏。 ![_20250725000241.png](https://h1.appinn.me/file/1753372979216__20250725000241.png) 总的来说，基于 github action 的服务监控更适合 1. 当做服务监控的服务监控使用，在服务监控宕机时发出提醒。 2. 当做第二重服务监控用，得到其他国家的访问节点，以防单一网络节点故障误判。 ---
作者： ![ch3nyang](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ch3nyang/32/68581_2.png) [@ch3nyang](https://meta.appinn.net/u/ch3nyang)\ 发布日期： [2025 年7 月 24 日 16:21 UTC](https://meta.appinn.net/t/topic/73616/3 "2025-07-24T16:21:50Z")
是的，我也发现了这个问题，似乎还没有什么好的解决办法。 另一个问题是，如果频率设置过高，Action 会隔段时间就执行失败，并且没有 GitHub Pro 的用户可能会因此触发额度限制 ---
作者： ![tjsky](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/tjsky/32/31059_2.png) [@tjsky](https://meta.appinn.net/u/tjsky)\ 发布日期： [2025 年7 月 24 日 16:31 UTC](https://meta.appinn.net/t/topic/73616/4 "2025-07-24T16:31:21Z")
邪门办法倒是有，有些项目可以模拟手动操作去执行 action :rofl: ---
作者： ![ClodQiu](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/clodqiu/32/52482_2.png) [@ClodQiu](https://meta.appinn.net/u/ClodQiu)\ 发布日期： [2025 年7 月 25 日 04:12 UTC](https://meta.appinn.net/t/topic/73616/5 "2025-07-25T04:12:21Z")
似乎跟 [https://status.shrimp.netlib.re](https://status.shrimp.netlib.re) 这个是一样的原理 ---
作者： ![Qingwa](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/qingwa/32/58632_2.png) [@Qingwa](https://meta.appinn.net/u/Qingwa)\ 发布日期： [2025 年7 月 25 日 04:12 UTC](https://meta.appinn.net/t/topic/73616/6 "2025-07-25T04:12:55Z")
我也有一个 > **[Appinn Status｜小众软件服务器的在线状态](https://status.appinn.com/)** ---
作者： ![tjsky](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/tjsky/32/31059_2.png) [@tjsky](https://meta.appinn.net/u/tjsky)\ 发布日期： [2025 年7 月 25 日 08:19 UTC](https://meta.appinn.net/t/topic/73616/7 "2025-07-25T08:19:03Z")
建议：增加一个服务器证书有效期检测的功能，如果剩余有效期不足1、3、7天则发送邮件提醒 （因为这东西都是自用，可以不用留设置邮箱功能，让action最后执行报错就行，gtihub会自动触发执行失败发送到账户的通知邮箱） ---
作者： ![ch3nyang](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ch3nyang/32/68581_2.png) [@ch3nyang](https://meta.appinn.net/u/ch3nyang)\ 发布日期： [2025 年7 月 25 日 13:24 UTC](https://meta.appinn.net/t/topic/73616/8 "2025-07-25T13:24:05Z")
好漂亮！想把这个响应时间的图给学走 :star_struck: 但我有个问题，这个时间是怎么计算的？是多地访问取平均还是只测量了一次 ---
作者： ![ch3nyang](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ch3nyang/32/68581_2.png) [@ch3nyang](https://meta.appinn.net/u/ch3nyang)\ 发布日期： [2025 年7 月 25 日 13:26 UTC](https://meta.appinn.net/t/topic/73616/9 "2025-07-25T13:26:01Z")
收到，这个已经在开发了 邮箱/微信通知我也考虑过，不过对于运行在Github Actions 的服务来说，肯定要通过第三方服务，这会增加用户使用难度，所以等后面有时间再搞 ---
作者： ![xxynet](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/x/b19c9b/32.png) [@xxynet](https://meta.appinn.net/u/xxynet)\ 发布日期： [2025 年7 月 26 日 04:08 UTC](https://meta.appinn.net/t/topic/73616/10 "2025-07-26T04:08:20Z")
我用Uptime搭建的监控页面 [XXY Server Status](https://status.xuxiny.top/) ---
作者： ![w568w](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/w568w/32/7148_2.png) [@w568w](https://meta.appinn.net/u/w568w)\ 发布日期： [2025 年7 月 26 日 06:59 UTC](https://meta.appinn.net/t/topic/73616/11 "2025-07-26T06:59:33Z")
居然没人提 Kener？这个自部署场景下真的好用，支持的协议和功能几乎和商业 Uptime Page 一样全 > **[GitHub - rajnandan1/kener: Stunning status pages, batteries included!](https://github.com/rajnandan1/kener)** > > Stunning status pages, batteries included! ---
作者： ![eman](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/e/94ad74/32.png) [@eman](https://meta.appinn.net/u/eman)\ 发布日期： [2025 年7 月 28 日 05:27 UTC](https://meta.appinn.net/t/topic/73616/12 "2025-07-28T05:27:26Z")
建议写一写部署到GitHub pages的步骤 :grin: ---
作者： ![ch3nyang](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ch3nyang/32/68581_2.png) [@ch3nyang](https://meta.appinn.net/u/ch3nyang)\ 发布日期： [2025 年8 月 2 日 09:12 UTC](https://meta.appinn.net/t/topic/73616/13 "2025-08-02T09:12:44Z")
:hugs: 没问题的 ---
作者： ![ch3nyang](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ch3nyang/32/68581_2.png) [@ch3nyang](https://meta.appinn.net/u/ch3nyang)\ 发布日期： [2025 年8 月 2 日 16:36 UTC](https://meta.appinn.net/t/topic/73616/14 "2025-08-02T16:36:20Z")
已实现 :face_blowing_a_kiss: