作为站长，最怕的事情莫过于：你的网站宕机了，你自己却是最后一个知道的。用户访问不了，客服电话被打爆，等你登录服务器排查时，可能已经过去了好几个小时——流量损失了、用户信任也打了折扣。市面上虽然有不少监控服务，但要么收费不菲，要么免费版限制太多。今天介绍一个完全不同的方案：UptimeFlare——一个基于 Cloudflare Workers 和 Pages 的开源、免费、Serverless 的网站状态监控工具。
一、UptimeFlare 是什么？
UptimeFlare 是一个完全运行在 Cloudflare 生态上的开源项目，由开发者 lyc8503 创建。它利用 Cloudflare Workers 的全球网络来监控你的网站状态，监控数据存储在 D1 数据库中，状态页面则通过 Cloudflare Pages 托管。整个架构不需要任何服务器，完全 Serverless，而且全部在 Cloudflare 免费额度内运行。
它的核心能力相当可观：支持最多 50 个监控目标，每个目标可以设置 1 分钟的最低检测间隔，支持 HTTP/HTTPS 和 TCP 端口检测，可以自定义请求头、请求体、预期状态码和关键词验证，历史数据保留 90 天。监控结果通过一个漂亮的状态页面展示，支持暗色模式和多语言（中文、英文、日文）。当网站出现异常时，可以通过 Telegram、企业微信、Pushover、Apprise 等多种渠道发送告警通知——而且这一切都是免费的。
二、快速部署指南
部署 UptimeFlare 不需要安装任何本地开发工具，整个过程通过 GitHub 和 Cloudflare Dashboard 完成，非常适合不熟悉命令行的站长。
2.1 准备工作
首先，你需要一个 Cloudflare 账号和一个 GitHub 账号。如果你还没有 Cloudflare Workers 的体验，需要先打开 Workers 仪表盘一次，系统会自动为你创建一个 workers.dev 子域名——这是后续部署的基础。
接下来创建一个 Cloudflare API Token。进入 Cloudflare Dashboard → My Profile → API Tokens → Create Token，选择 “Edit Cloudflare Workers” 模板，然后额外手动添加 D1 数据库的 Edit 权限。这一步很容易被遗漏——UptimeFlare 在 2026 年初从 KV 迁移到了 D1 数据库，旧的 Token 如果不包含 D1 权限，部署会失败。
2.2 Fork 模板仓库
访问 UptimeFlare 的 GitHub 模板仓库（lyc8503/uptimeflare），点击 “Use this template” 创建一个你自己的仓库。建议将仓库设为 Private，这样你的监控配置和通知信息不会公开暴露。
2.3 配置 Secrets
在你新创建的仓库中，进入 Settings → Secrets and variables → Actions，添加一个名为 CLOUDFLARE_API_TOKEN 的 Secret，值填入刚才创建的 API Token。这个 Token 会被 GitHub Actions 用来部署 Worker 和 Pages，所以绝对不要将其写入代码或配置文件中。
2.4 编辑监控配置
仓库根目录下的 uptime.config.ts 是核心配置文件。你需要修改 monitors 数组来添加你要监控的网站：
monitors: [
{
id: "my-blog",
name: "我的博客",
method: "GET",
url: "https://kepu51.com",
expectedCodes: [200],
timeout: 10000,
responseKeyword: "科普51"
},
{
id: "my-api",
name: "API服务",
method: "GET",
url: "https://api.kepu51.com/health",
expectedCodes: [200, 301]
}
],notification.url 用来配置告警通知。以 Telegram 为例，格式为：https://api.telegram.org/bot<BOT_TOKEN>/sendMessage?chat_id=<CHAT_ID>&text=$MSG。其中 $MSG 是消息内容的占位符，UptimeFlare 会自动替换为实际的告警信息。
2.5 提交代码自动部署
修改完配置后，commit 并 push 到 GitHub 仓库。仓库中预置的 GitHub Actions 工作流会自动开始构建和部署。整个流程通常只需要 2-3 分钟。部署完成后，你可以在 Cloudflare Pages 仪表盘中找到你的状态页面地址，格式为 https://<项目名>.pages.dev。
首次部署后大约 5 分钟，第一个监控数据就会出现。你可以在状态页面上直观地看到每个监控目标的在线率、响应时间趋势和历史事件记录。
三、进阶配置技巧
3.1 多地域检测
UptimeFlare 默认通过 Cloudflare Workers 的全球网络进行检测，覆盖 310+ 个城市。但你也可以通过 Durable Objects 配置特定地区的检测节点——在 checkProxy 中设置 worker://weur（西欧）、worker://wnam（北美西部）等区域代码，实现从特定地理位置的定向检测。这对于判断是全局宕机还是区域性网络问题非常有帮助。
3.2 自定义域名和密码保护
在 Cloudflare Pages 的自定义域设置中绑定你的域名，就可以通过自己的域名访问状态页面，看起来更专业。在配置文件中设置 password: "your_password" 即可为页面添加密码保护，防止监控数据被公开访问。
3.3 维护窗口设置
当你要对服务器进行计划内维护时，可以在配置中添加 maintenances 字段来避免误报警：
maintenances: [
{
monitorIds: ["my-blog"],
start: "2026-06-15T02:00:00Z",
end: "2026-06-15T04:00:00Z",
title: "服务器升级维护"
}
]四、常见问题解答（FAQ）
Q1：UptimeFlare 的免费额度够用吗？
完全够用。Cloudflare Workers 免费计划每天有 10 万次请求额度，D1 数据库有 5GB 存储和每月 500 万次读取。对于监控 10-20 个网站、每分钟检测一次的场景来说，这些额度连 5% 都用不到。唯一需要注意的是 Workers 免费计划的 CPU 时间限制（每天 10 分钟），但 UptimeFlare 的 Worker 执行效率很高，监控 10 个站点大约只消耗 1 分钟不到的 CPU 时间。
Q2：部署完成后没有收到数据怎么办？
首次部署后需要等待 5 分钟左右才会出现第一个监控数据点。如果等了 10 分钟仍然没有数据，检查以下几点：API Token 是否有 D1 数据库的 Edit 权限（2026 年初的迁移导致旧 Token 失效）；GitHub Actions 是否成功运行（在仓库 Actions 标签页查看运行日志）；Cloudflare Pages 是否部署成功（在 Pages 仪表盘检查构建状态）。
Q3：可以监控内网服务吗？
UptimeFlare 的监控节点运行在 Cloudflare 的全球网络上，因此只能监控公网可达的服务。如果你的内网服务需要通过 VPN 才能访问，可以考虑在 VPS 上部署一个健康检查端点，然后由 UptimeFlare 来监控这个端点。或者使用其他支持内网的监控方案（如哪吒探针）。
Q4：发生宕机时通知延迟有多久？
UptimeFlare 的检测间隔最短为 1 分钟，加上检测失败后的确认机制和通知投递时间，从网站实际宕机到你收到告警通知，通常延迟在 2-3 分钟以内。相比一些商业监控服务（如 Pingdom 免费版 15 分钟间隔），这个实时性已经相当不错了。
Q5：如何从旧版迁移到最新版？
UptimeFlare 在 2026 年初经历了一次重要的数据存储迁移（KV → D1），如果之前使用的是旧版本，建议直接 Fork 最新的模板仓库，然后手动将你的监控配置复制过来。具体的Breaking Changes 记录在项目的 Wiki 页面中，升级前务必查看。
五、总结
UptimeFlare 完美诠释了什么叫”小而美”——它没有花哨的仪表盘，没有复杂的部署流程，也没有隐藏的收费陷阱。它做的唯一一件事，就是帮你免费、可靠地监控网站状态，并在出问题时第一时间通知到你。对于个人站长和中小团队来说，这已经足够了。如果你还在用几十美元一年的付费监控服务，不妨试试 UptimeFlare——省下来的钱，给 VPS 升级一下配置不香吗？
原创文章，作者：kp51，如若转载，请注明出处：https://www.kepu51.com/instant-messaging/792.html
