如何使用 Upptime 免费搭建自己的状态站点把监控这件事整个儿搬进 GitHub 仓库——Actions 当探针、仓库当数据库、Pages 当 CDN、Issues 当事件簿。零服务器零月费愣是凑出一个能看能查能留痕的状态站。说是黑魔法也好说是穷人的智慧也罢反正它跑起来了。背景运维一个由十几个对外服务凑起来的小型产品矩阵时,到底通不通这事常常变成了口头禅。客户反馈说访问不了你 ssh 上去curl一遍发现是好的过几分钟它又挂了可你这次没盯到。商业监控Pingdom、UptimeRobot 的高级档、Datadog当然能解决只是要么按站点收费要么按请求次数收费对一个独立开发者来说成本和心智负担都不太划算而已。更关键的是状态页本身也得让用户能查。理想的样子是一个域名比如status.hagicode.com实时展示每个服务的可用率、响应时间曲线、历史事件故障时还能自动留痕、自动通知。传统做法要凑齐四件套——跑 cron 的服务器、存历史数据的数据库、前端站点、CDN。这四样一摆开运维成本立刻就盖过了被监控的服务本身毕竟杀鸡用了牛刀鸡还嫌挤。为了解决这些痛点我们做了一个决定整个监控方案直接搬到 GitHub 上。这个决定带来的变化可能比你想的还要大——稍后我再慢慢说。关于 HagiCode本文分享的方案来自我们在 HagiCode 项目里摸爬滚打的经验。HagiCode 是个 AI 代码助手项目对外吐出了网页、文档站、下载端点等十几个公共服务背后由 HagiCode-org/site 这个主仓库驱动着。这些站点必须稳定可用所以状态监控对我们不是可选项而是刚需。下面这套 Upptime 方案正是 HagiCode 实际生产环境在用的——不是我编的。分析Upptime 到底是怎么跑起来的Upptime 的本质其实是一份 GitHub 仓库模板加上六个由模板生成的 workflow。理解它的关键就是看清楚谁在什么时候、调用谁、产出什么落到哪里。把它拆开了看也就不那么神秘了。数据流一个配置文件驱动一切整个系统就绕着.upptimerc.yml这一个声明式配置文件转。HagiCode 的实际配置结构大概是这样owner:HagiCode-orgrepo:upptimesites:-name:HagiCode Websiteurl:https://hagicode.com-name:HagiCode Docsurl:https://docs.hagicode.com-name:Server Package Indexurl:https://index.hagicode.com/server/index.json# ... 共 14 个站点status-website:cname:status.hagicode.comlogoUrl:https://raw.githubusercontent.com/HagiCode-org/upptime/master/assets/upptime-icon.svgname:HagiCode StatusintroTitle:**HagiCode Status**introMessage:Real-time availability tracking for public HagiCode websites and download endpoints.navbar:-title:Statushref:/-title:GitHubhref:https://github.com/$OWNER/$REPO这里有两点值得拎出来说。第一sites既能监控网页返回 HTML也能监控纯 JSON 端点比如index.jsonUpptime 只看 HTTP 状态码和响应时间不做内容校验。第二cname指向status.hagicode.com这要求你得拥有该域名并把 DNS 指向 GitHub Pages——毕竟白嫖归白嫖域名还是要自己出的。六个 workflow 的分工.github/workflows/下所有文件顶部都有一行警告Do not edit this file directly!——它们由模板每周自动更新你只改.upptimerc.yml就好。每个 workflow 用 cron 触发调用同一个 actionupptime/uptime-monitorv1.42.6的不同子命令分工明确倒也省心Workflowcron命令作用uptime.yml*/5 * * * *update每 5 分钟探活写history/*.ymlresponse-time.yml—response-time计算响应时间统计graphs.yml—graphs生成日/周/月/年 PNG 曲线summary.yml—summary更新 README 里的状态表site.yml0 1 * * *site每日构建静态站部署到 Pagesupdate-template.yml0 0 * * *—每周同步上游模板uptime.yml的核心片段展示了探针是怎么跑的on:schedule:-cron:*/5 * * * *jobs:release:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:token:${{secrets.GH_PAT||github.token}}-name:Check endpoint statususes:upptime/uptime-monitorv1.42.6with:command:updateenv:GH_PAT:${{secrets.GH_PAT||github.token}}SECRETS_CONTEXT:${{toJson(secrets)}}site.yml则多了一步用peaceiris/actions-gh-pagesv4把构建产物推到gh-pages分支-uses:peaceiris/actions-gh-pagesv4with:github_token:${{secrets.GH_PAT||github.token}}publish_dir:site/status-page/__sapper__/export/user_name:Upptime Botuser_email:73812536upptime-botusers.noreply.github.com数据落盘文件即数据库监控结果不存数据库而是直接以文件形式 commit 回仓库。这听起来有点野但用起来倒也踏实。每个站点有三类产物。状态快照history/{slug}.yml例如history/hagi-code-website.ymlurl:https://hagicode.comstatus:upcode:200responseTime:96lastUpdated:2026-06-17T00:22:34.485ZstartTime:2026-03-24T10:07:32.531Zshields.io 的 endpoint 徽章数据源api/{slug}/response-time.json、uptime.json{schemaVersion:1,label:response time,message:739 ms,color:yellow}以及响应时间曲线图graphs/{slug}/response-time-{day,week,month,year}.png。这套文件即数据库的取舍其实想得挺清楚写多读少、规模可控每个站点一天约 288 条采样存增量而非全量、天然带版本历史、零基础设施。代价嘛就是仓库会持续长大偶尔得回头关心一下它而已。事件与通知Issues 当事件簿故障留痕靠 GitHub Issues配合仓库自带的两个模板.github/ISSUE_TEMPLATE/bug_report.md用户报障和maintainance-event.md计划性维护。维护模板用 frontmatter 表达时间窗!-- start: 2021-08-24T13:00:00.220Z end: 2021-08-24T14:00:00.220Z expectedDown: google, hacker-news --Upptime 会解析这些 Issue把正在维护和已发生事件渲染到状态页和 README 上。通知则靠 Issue 自身的 watch 机制外加可配置的 webhook、Slack、Telegram在.upptimerc.yml顶部声明notificationsHagiCode 的示例仓库目前没启用毕竟能少一样是一样。解决五步复刻一套状态站复刻一套 HagiCode 同款状态站从零到上线一共五步。说是五步其实每步都不长慢慢来就是。第 1 步从模板创建仓库别git clone后改直接用 GitHub 的 “Use this template” 创建仓库例如your-org/upptime。模板已经内置了全部 workflow、Issue 模板和静态站点骨架。clone 到本地后唯一需要手改的就是.upptimerc.yml——其它的留着别动就好。第 2 步编辑.upptimerc.yml把owner/repo改成你的sites列出要监控的地址status-website配置站点。最小可用版本大概是这样owner:your-orgrepo:upptimesites:-name:Main Siteurl:https://example.com-name:API Healthurl:https://api.example.com/healthexpectedStatusCodes:-200status-website:cname:status.example.com# 没有域名可删掉用默认的 your-org.github.io/upptimename:Example StatusintroTitle:**Example Status**introMessage:服务可用性实时监控navbar:-title:Statushref:/-title:GitHubhref:https://github.com/$OWNER/$REPO进阶项expectedStatusCodes限定可接受的状态码默认 200-399headers自定义请求头用于需要鉴权的端点maxResponseTime标记慢响应。这些都看你需要按需取用罢了。第 3 步配置 Secret 与权限workflow 默认用${{ secrets.GH_PAT || github.token }}。github.token能跑通基本流程但有两个限制会咬人默认 token 触发的 workflow 不会再触发下游 workflow防止循环导致探活 → 建 Issue → 通知这条链断在中间。跨仓库操作比如多组织权限不足。推荐新建一个 PAT需要repoworkflow权限存为仓库 SecretGH_PAT。update-template.yml里专门有一段检查没有GH_PAT就跳过模板自动更新并打印 warning所以这个 secret 不只是可选项更是省心的关键。第 4 步开启 GitHub Pages仓库 Settings → Pages → Source 选Deploy from a branch分支选gh-pages、目录/root。site.yml每天凌晨 1 点会自动把构建产物推到这个分支。如果配了cname再到你的 DNS 服务商加一条 CNAME 记录指向your-org.github.io。第一次手动触发一下也好Actions 页面找到 “Static Site CI” → Run workflow不用傻等定时任务毕竟能早一秒看到结果心里就早一秒踏实。第 5 步验证与维护push 配置后去 Actions 看 “Uptime CI” 是否每 5 分钟跑一次、history/是否开始出现*.yml文件。状态页地址就是https://your-org.github.io/upptime/或你的自定义域名。后续加站点、改域名只动.upptimerc.yml一个文件就行workflow 全自动。HagiCode 这一年多就靠这套机制维护 14 个端点的可用性基本没怎么操心过。实践踩过的坑都替你趟过了下面这几条是 HagiCode 实际运行中积累下来的经验写出来也好让你少走点弯路。实践 1监控粒度选择HagiCode 把网页https://hagicode.com和纯数据端点https://index.hagicode.com/server/index.json放在同一个sites列表里。对 JSON 端点Upptime 会请求并解析 HTTP 状态码但不校验内容结构。如果你需要返回 200 但内容错误这种深度检查得用expectedStatusCodes加上外部探针来补Upptime 本身只做黑盒 HTTP 检查——它只看脸色不读心事。实践 2响应时间徽章的妙用api/{slug}/response-time.json是 shields.io 的 endpoint 徽章 数据源。HagiCode 的 README 里大量引用这种 URLhttps://img.shields.io/endpoint?urlhttps%3A%2F%2Fraw.githubusercontent.com%2FHagiCode-org%2Fupptime%2FHEAD%2Fapi%2Fhagi-code-website%2Fresponse-time.json这样一来你就能在任何 Markdown项目 README、博客、第三方页面里嵌入实时响应时间徽章颜色由message里的数值和color字段驱动。注意用HEAD而不是master/main引用 raw 文件能避免分支改名后大面积失效——细节之处藏着安稳。实践 3仓库体积控制每 5 分钟一次采样一年下来history/会累积出可观的体积。Upptime 用增量 YAML 而非全量日志相对克制但仍建议定期看一眼仓库大小。如果某个站点监控价值下降了从sites移除即可对应的历史文件也可以手动清理掉毕竟舍不得删仓库迟早会臃肿给你看。实践 4维护事件的真实用法maintainance-event.md不是摆设。计划发版前按模板开一个 Issue填好start/end/expectedDownUpptime 会把这段时间内的对应站点标记为计划内维护不计入可用率统计避免一次正常发版把全年 SLA 拉低。HagiCode 的expectedDown支持逗号分隔的站点名列表与sites[].name一一对应。实践 5模板更新与自定义的边界所有.github/workflows/*.yml顶部的Do not edit this file directly!不是吓唬人的。update-template.yml每周会用上游模板覆盖这些文件。需要自定义行为时正确做法是在.upptimerc.yml里用官方支持的配置项如skipTopics、customStatusWebsite、runnerSettings而不是去改 workflow。实在要改 workflow要么关掉update-template.yml要么 fork 出来自己维护模板——后者会失去无痛升级得失之间自己掂量罢了。实践 6免费额度的现实约束GitHub Actions 对公开仓库免费、不限时长Upptime 设计上正是利用了这一点。私有仓库每月有 2000 分钟免费额度而uptime.yml每 5 分钟跑一次、每次约 1 分钟单这一项一个月就大概 8640 分钟会超额。所以 Upptime 仓库必须是 public这是免费两个字的前提——别图保密开成 private然后收到账单那就尴尬了。总结回到开头那个问题监控一堆对外服务到底有没有便宜的解法HagiCode 的答案是——有而且便宜得让你怀疑这是不是真的。Upptime 把监控拆成了四个 GitHub 原生组件探针 GitHub Actions 的 cron数据库 仓库里的 YAML/JSON 文件CDN GitHub Pages事件簿 GitHub Issues你得到的是实时可用率、响应时间曲线、历史事件、可用率徽章、自定义域名、自动通知全部零服务器、零月费。代价是要保持仓库公开以及偶尔关心一下仓库体积。其实这点代价比起手搓一套监控已经轻得太多。这套方案之所以能跑通背后是 GitHub 生态对开源项目的诚意补贴。如果你也在维护一个多站点的小型产品矩阵强烈建议花一个下午把它搭起来比手搓监控省心太多。参考资料Upptime 官方仓库shields.io endpoint 徽章文档GitHub Actions 定时任务文档HagiCode 状态站实例总结围绕“如何使用 Upptime 免费搭建自己的状态站点”更稳妥的推进方式是先把关键配置、依赖边界和落地路径逐步跑通再补齐优化细节。当目标、步骤和验收点都明确之后这类方案通常就能更顺畅地进入实际交付。原文与版权说明感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。本内容采用人工智能辅助协作,最终内容由作者审核并确认。本文作者: newbe36524原文链接: https://docs.hagicode.com/go?platformcsdntarget%2Fblog%2F2026-06-18-how-to-use-upptime-for-free-status-page%2F版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
如何使用 Upptime 免费搭建自己的状态站点
发布时间：2026/6/19 19:13:26
如何使用 Upptime 免费搭建自己的状态站点把监控这件事整个儿搬进 GitHub 仓库——Actions 当探针、仓库当数据库、Pages 当 CDN、Issues 当事件簿。零服务器零月费愣是凑出一个能看能查能留痕的状态站。说是黑魔法也好说是穷人的智慧也罢反正它跑起来了。背景运维一个由十几个对外服务凑起来的小型产品矩阵时,到底通不通这事常常变成了口头禅。客户反馈说访问不了你 ssh 上去curl一遍发现是好的过几分钟它又挂了可你这次没盯到。商业监控Pingdom、UptimeRobot 的高级档、Datadog当然能解决只是要么按站点收费要么按请求次数收费对一个独立开发者来说成本和心智负担都不太划算而已。更关键的是状态页本身也得让用户能查。理想的样子是一个域名比如status.hagicode.com实时展示每个服务的可用率、响应时间曲线、历史事件故障时还能自动留痕、自动通知。传统做法要凑齐四件套——跑 cron 的服务器、存历史数据的数据库、前端站点、CDN。这四样一摆开运维成本立刻就盖过了被监控的服务本身毕竟杀鸡用了牛刀鸡还嫌挤。为了解决这些痛点我们做了一个决定整个监控方案直接搬到 GitHub 上。这个决定带来的变化可能比你想的还要大——稍后我再慢慢说。关于 HagiCode本文分享的方案来自我们在 HagiCode 项目里摸爬滚打的经验。HagiCode 是个 AI 代码助手项目对外吐出了网页、文档站、下载端点等十几个公共服务背后由 HagiCode-org/site 这个主仓库驱动着。这些站点必须稳定可用所以状态监控对我们不是可选项而是刚需。下面这套 Upptime 方案正是 HagiCode 实际生产环境在用的——不是我编的。分析Upptime 到底是怎么跑起来的Upptime 的本质其实是一份 GitHub 仓库模板加上六个由模板生成的 workflow。理解它的关键就是看清楚谁在什么时候、调用谁、产出什么落到哪里。把它拆开了看也就不那么神秘了。数据流一个配置文件驱动一切整个系统就绕着.upptimerc.yml这一个声明式配置文件转。HagiCode 的实际配置结构大概是这样owner:HagiCode-orgrepo:upptimesites:-name:HagiCode Websiteurl:https://hagicode.com-name:HagiCode Docsurl:https://docs.hagicode.com-name:Server Package Indexurl:https://index.hagicode.com/server/index.json# ... 共 14 个站点status-website:cname:status.hagicode.comlogoUrl:https://raw.githubusercontent.com/HagiCode-org/upptime/master/assets/upptime-icon.svgname:HagiCode StatusintroTitle:**HagiCode Status**introMessage:Real-time availability tracking for public HagiCode websites and download endpoints.navbar:-title:Statushref:/-title:GitHubhref:https://github.com/$OWNER/$REPO这里有两点值得拎出来说。第一sites既能监控网页返回 HTML也能监控纯 JSON 端点比如index.jsonUpptime 只看 HTTP 状态码和响应时间不做内容校验。第二cname指向status.hagicode.com这要求你得拥有该域名并把 DNS 指向 GitHub Pages——毕竟白嫖归白嫖域名还是要自己出的。六个 workflow 的分工.github/workflows/下所有文件顶部都有一行警告Do not edit this file directly!——它们由模板每周自动更新你只改.upptimerc.yml就好。每个 workflow 用 cron 触发调用同一个 actionupptime/uptime-monitorv1.42.6的不同子命令分工明确倒也省心Workflowcron命令作用uptime.yml*/5 * * * *update每 5 分钟探活写history/*.ymlresponse-time.yml—response-time计算响应时间统计graphs.yml—graphs生成日/周/月/年 PNG 曲线summary.yml—summary更新 README 里的状态表site.yml0 1 * * *site每日构建静态站部署到 Pagesupdate-template.yml0 0 * * *—每周同步上游模板uptime.yml的核心片段展示了探针是怎么跑的on:schedule:-cron:*/5 * * * *jobs:release:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:token:${{secrets.GH_PAT||github.token}}-name:Check endpoint statususes:upptime/uptime-monitorv1.42.6with:command:updateenv:GH_PAT:${{secrets.GH_PAT||github.token}}SECRETS_CONTEXT:${{toJson(secrets)}}site.yml则多了一步用peaceiris/actions-gh-pagesv4把构建产物推到gh-pages分支-uses:peaceiris/actions-gh-pagesv4with:github_token:${{secrets.GH_PAT||github.token}}publish_dir:site/status-page/__sapper__/export/user_name:Upptime Botuser_email:73812536upptime-botusers.noreply.github.com数据落盘文件即数据库监控结果不存数据库而是直接以文件形式 commit 回仓库。这听起来有点野但用起来倒也踏实。每个站点有三类产物。状态快照history/{slug}.yml例如history/hagi-code-website.ymlurl:https://hagicode.comstatus:upcode:200responseTime:96lastUpdated:2026-06-17T00:22:34.485ZstartTime:2026-03-24T10:07:32.531Zshields.io 的 endpoint 徽章数据源api/{slug}/response-time.json、uptime.json{schemaVersion:1,label:response time,message:739 ms,color:yellow}以及响应时间曲线图graphs/{slug}/response-time-{day,week,month,year}.png。这套文件即数据库的取舍其实想得挺清楚写多读少、规模可控每个站点一天约 288 条采样存增量而非全量、天然带版本历史、零基础设施。代价嘛就是仓库会持续长大偶尔得回头关心一下它而已。事件与通知Issues 当事件簿故障留痕靠 GitHub Issues配合仓库自带的两个模板.github/ISSUE_TEMPLATE/bug_report.md用户报障和maintainance-event.md计划性维护。维护模板用 frontmatter 表达时间窗!-- start: 2021-08-24T13:00:00.220Z end: 2021-08-24T14:00:00.220Z expectedDown: google, hacker-news --Upptime 会解析这些 Issue把正在维护和已发生事件渲染到状态页和 README 上。通知则靠 Issue 自身的 watch 机制外加可配置的 webhook、Slack、Telegram在.upptimerc.yml顶部声明notificationsHagiCode 的示例仓库目前没启用毕竟能少一样是一样。解决五步复刻一套状态站复刻一套 HagiCode 同款状态站从零到上线一共五步。说是五步其实每步都不长慢慢来就是。第 1 步从模板创建仓库别git clone后改直接用 GitHub 的 “Use this template” 创建仓库例如your-org/upptime。模板已经内置了全部 workflow、Issue 模板和静态站点骨架。clone 到本地后唯一需要手改的就是.upptimerc.yml——其它的留着别动就好。第 2 步编辑.upptimerc.yml把owner/repo改成你的sites列出要监控的地址status-website配置站点。最小可用版本大概是这样owner:your-orgrepo:upptimesites:-name:Main Siteurl:https://example.com-name:API Healthurl:https://api.example.com/healthexpectedStatusCodes:-200status-website:cname:status.example.com# 没有域名可删掉用默认的 your-org.github.io/upptimename:Example StatusintroTitle:**Example Status**introMessage:服务可用性实时监控navbar:-title:Statushref:/-title:GitHubhref:https://github.com/$OWNER/$REPO进阶项expectedStatusCodes限定可接受的状态码默认 200-399headers自定义请求头用于需要鉴权的端点maxResponseTime标记慢响应。这些都看你需要按需取用罢了。第 3 步配置 Secret 与权限workflow 默认用${{ secrets.GH_PAT || github.token }}。github.token能跑通基本流程但有两个限制会咬人默认 token 触发的 workflow 不会再触发下游 workflow防止循环导致探活 → 建 Issue → 通知这条链断在中间。跨仓库操作比如多组织权限不足。推荐新建一个 PAT需要repoworkflow权限存为仓库 SecretGH_PAT。update-template.yml里专门有一段检查没有GH_PAT就跳过模板自动更新并打印 warning所以这个 secret 不只是可选项更是省心的关键。第 4 步开启 GitHub Pages仓库 Settings → Pages → Source 选Deploy from a branch分支选gh-pages、目录/root。site.yml每天凌晨 1 点会自动把构建产物推到这个分支。如果配了cname再到你的 DNS 服务商加一条 CNAME 记录指向your-org.github.io。第一次手动触发一下也好Actions 页面找到 “Static Site CI” → Run workflow不用傻等定时任务毕竟能早一秒看到结果心里就早一秒踏实。第 5 步验证与维护push 配置后去 Actions 看 “Uptime CI” 是否每 5 分钟跑一次、history/是否开始出现*.yml文件。状态页地址就是https://your-org.github.io/upptime/或你的自定义域名。后续加站点、改域名只动.upptimerc.yml一个文件就行workflow 全自动。HagiCode 这一年多就靠这套机制维护 14 个端点的可用性基本没怎么操心过。实践踩过的坑都替你趟过了下面这几条是 HagiCode 实际运行中积累下来的经验写出来也好让你少走点弯路。实践 1监控粒度选择HagiCode 把网页https://hagicode.com和纯数据端点https://index.hagicode.com/server/index.json放在同一个sites列表里。对 JSON 端点Upptime 会请求并解析 HTTP 状态码但不校验内容结构。如果你需要返回 200 但内容错误这种深度检查得用expectedStatusCodes加上外部探针来补Upptime 本身只做黑盒 HTTP 检查——它只看脸色不读心事。实践 2响应时间徽章的妙用api/{slug}/response-time.json是 shields.io 的 endpoint 徽章 数据源。HagiCode 的 README 里大量引用这种 URLhttps://img.shields.io/endpoint?urlhttps%3A%2F%2Fraw.githubusercontent.com%2FHagiCode-org%2Fupptime%2FHEAD%2Fapi%2Fhagi-code-website%2Fresponse-time.json这样一来你就能在任何 Markdown项目 README、博客、第三方页面里嵌入实时响应时间徽章颜色由message里的数值和color字段驱动。注意用HEAD而不是master/main引用 raw 文件能避免分支改名后大面积失效——细节之处藏着安稳。实践 3仓库体积控制每 5 分钟一次采样一年下来history/会累积出可观的体积。Upptime 用增量 YAML 而非全量日志相对克制但仍建议定期看一眼仓库大小。如果某个站点监控价值下降了从sites移除即可对应的历史文件也可以手动清理掉毕竟舍不得删仓库迟早会臃肿给你看。实践 4维护事件的真实用法maintainance-event.md不是摆设。计划发版前按模板开一个 Issue填好start/end/expectedDownUpptime 会把这段时间内的对应站点标记为计划内维护不计入可用率统计避免一次正常发版把全年 SLA 拉低。HagiCode 的expectedDown支持逗号分隔的站点名列表与sites[].name一一对应。实践 5模板更新与自定义的边界所有.github/workflows/*.yml顶部的Do not edit this file directly!不是吓唬人的。update-template.yml每周会用上游模板覆盖这些文件。需要自定义行为时正确做法是在.upptimerc.yml里用官方支持的配置项如skipTopics、customStatusWebsite、runnerSettings而不是去改 workflow。实在要改 workflow要么关掉update-template.yml要么 fork 出来自己维护模板——后者会失去无痛升级得失之间自己掂量罢了。实践 6免费额度的现实约束GitHub Actions 对公开仓库免费、不限时长Upptime 设计上正是利用了这一点。私有仓库每月有 2000 分钟免费额度而uptime.yml每 5 分钟跑一次、每次约 1 分钟单这一项一个月就大概 8640 分钟会超额。所以 Upptime 仓库必须是 public这是免费两个字的前提——别图保密开成 private然后收到账单那就尴尬了。总结回到开头那个问题监控一堆对外服务到底有没有便宜的解法HagiCode 的答案是——有而且便宜得让你怀疑这是不是真的。Upptime 把监控拆成了四个 GitHub 原生组件探针 GitHub Actions 的 cron数据库 仓库里的 YAML/JSON 文件CDN GitHub Pages事件簿 GitHub Issues你得到的是实时可用率、响应时间曲线、历史事件、可用率徽章、自定义域名、自动通知全部零服务器、零月费。代价是要保持仓库公开以及偶尔关心一下仓库体积。其实这点代价比起手搓一套监控已经轻得太多。这套方案之所以能跑通背后是 GitHub 生态对开源项目的诚意补贴。如果你也在维护一个多站点的小型产品矩阵强烈建议花一个下午把它搭起来比手搓监控省心太多。参考资料Upptime 官方仓库shields.io endpoint 徽章文档GitHub Actions 定时任务文档HagiCode 状态站实例总结围绕“如何使用 Upptime 免费搭建自己的状态站点”更稳妥的推进方式是先把关键配置、依赖边界和落地路径逐步跑通再补齐优化细节。当目标、步骤和验收点都明确之后这类方案通常就能更顺畅地进入实际交付。原文与版权说明感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。本内容采用人工智能辅助协作,最终内容由作者审核并确认。本文作者: newbe36524原文链接: https://docs.hagicode.com/go?platformcsdntarget%2Fblog%2F2026-06-18-how-to-use-upptime-for-free-status-page%2F版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
相关文章
Anime.js路径动画终极指南：从贝塞尔曲线到高级运动控制
Anime.js路径动画终极指南：从贝塞尔曲线到高级运动控制 【免费下载链接】anime JavaScript animation engine 项目地址: https://gitcode.com/GitHub_Trending/an/anime 在当今Web动画领域，创建流畅自然的运动轨迹是提升用户体验的关键。传统直线…
Cursor Pro账户管理终极指南：开源工具实现多账户自由切换与机器ID重置
Cursor Pro账户管理终极指南：开源工具实现多账户自由切换与机器ID重置 【免费下载链接】cursor-free-vip [Support 0.45]（Multi Language 多语言）自动注册 Cursor Ai ，自动重置机器ID ， 免费升级使用Pro 功能: Youve r…
H2O Wave实战指南：5步构建高效实时仪表盘的一站式解决方案
H2O Wave实战指南：5步构建高效实时仪表盘的一站式解决方案 【免费下载链接】wave Realtime Web Apps and Dashboards for Python and R 项目地址: https://gitcode.com/gh_mirrors/wav/wave H2O Wave是一个专为Python和R开发者设计的实时Web应用框架…
深入解析BDLC控制器：J1850总线非破坏性仲裁机制与汽车电子通信实践
1. 项目概述与核心价值在嵌入式系统，尤其是汽车电子领域，多节点之间的可靠通信是系统稳定运行的基石。不同于我们熟知的CAN总线，在更早的北美汽车网络标准中，SAE J1850协议扮演了关键角色，它定义了车辆内部模块之间低速…
MCF532x微处理器低功耗模式深度解析与实战配置指南
1. 项目概述：从数据手册到设计实战做嵌入式开发，尤其是涉及电池供电或者对散热有严格限制的项目，功耗管理从来都不是一个“锦上添花”的选项，而是决定产品成败的核心指标之一。我经手过不少便携式数据采集设备和工业现场的低功耗控…
计算机教材策划与写作：如何将AI与云计算前沿知识结构化
1. 项目概述：一本好教材是如何诞生的写一本计算机教材，这事儿我干了十几年。从最初给出版社写零散的章节，到后来独立策划并完成几本被高校和培训机构采用的教材，我踩过的坑、熬过的夜，加起来能写另一本“避坑指南”。很…
2026年好用的claude服务厂家
在当今数字化飞速发展的时代，智能服务在各个领域的应用愈发广泛，Claude作为一款强大的智能工具，受到了众多用户的关注。2026年，中米公司凭借其优质的Claude服务脱颖而出，成为众多用户的首选。下面我们就来详细了解一下…
终极WELearn网课助手完全指南：3分钟掌握智能学习技巧
终极WELearn网课助手完全指南：3分钟掌握智能学习技巧 【免费下载链接】WELearnHelper 显示WE Learn随行课堂题目答案；支持班级测试；自动答题；刷时长；基于生成式AI(ChatGPT)的答案生成 项目地址: https://gitcode.com…
终极指南：使用OpenCore Legacy Patcher免费升级老旧Mac到最新macOS系统
终极指南：使用OpenCore Legacy Patcher免费升级老旧Mac到最新macOS系统 【免费下载链接】OpenCore-Legacy-Patcher Experience macOS just like before 项目地址: https://gitcode.com/GitHub_Trending/op/OpenCore-Legacy-Patcher 你是否有一台被苹果官方&q…
PowerPC 601指令集深度解析：分支、陷阱与处理器控制指令实战指南
1. PowerPC 601指令集：程序流与系统控制的基石如果你曾经在嵌入式系统、早期的苹果Power Macintosh，或是任天堂GameCube/Wii这类经典游戏主机上做过开发，那么PowerPC这个名字对你来说一定不陌生。作为RISC架构黄金时代的代表作之一࿰…
OpenCore Legacy Patcher终极指南：四步让老旧Mac免费升级最新macOS
OpenCore Legacy Patcher终极指南：四步让老旧Mac免费升级最新macOS 【免费下载链接】OpenCore-Legacy-Patcher Experience macOS just like before 项目地址: https://gitcode.com/GitHub_Trending/op/OpenCore-Legacy-Patcher 还在为苹果官方放弃的老旧Mac无…
Mermaid Live Editor：重塑技术文档图表创作体验的专业工具
Mermaid Live Editor：重塑技术文档图表创作体验的专业工具 【免费下载链接】mermaid-live-editor Edit, preview and share mermaid charts/diagrams. New implementation of the live editor. 项目地址: https://gitcode.com/GitHub_Trending/me/mermaid-live-ed…
音乐文件解锁实战指南：3个场景解决你的播放困境
音乐文件解锁实战指南：3个场景解决你的播放困境 【免费下载链接】unlock-music 在浏览器中解锁加密的音乐文件。原仓库： 1. https://github.com/unlock-music/unlock-music ；2. https://git.unlock-music.dev/um/web 项目地址: https://git…
从Landsat到高分系列：手把手教你选择适合自己项目的遥感卫星数据
遥感卫星数据选型实战指南：从参数解析到场景化应用当面对GEE、PIE-Engine等云平台上数十种遥感数据源时，许多研究者常陷入选择困难——Landsat的历史连续性、Sentinel-2的红边波段优势、高分系列的亚米级分辨率各有千秋。本文将打破常规参数罗列式对比&a…
MC68302 AutoBaud技术：硬件级串口波特率自动检测原理与实现
1. 项目概述：MC68302 AutoBaud技术深度解析在嵌入式系统开发，尤其是那些需要与外部设备进行串口通信的场景里，最让人头疼的环节之一就是波特率匹配。想象一下，你设计了一个数据采集终端，需要连接来自不同厂家、不同年代…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…