UptimeFlare：免费开源的多区域网站状态监控轻松部署到 Workers

发布于2025年12月18日

更新于2025年12月18日

前言

很久之前介绍过一款同样开源的站点监控工具 Uptime Kuma，功能非常的丰富，可以满足绝大多数网站状态监控的需求，但也存在一个较为致命的问题——需要部署在自己的 VPS 上。

当然，与其说这是 Uptime Kuma 的缺点，不如说是自身条件的限制。毕竟谁也不能保证部署了 Uptime Kuma 的主控服务器始终稳定，一旦主控服务器或网络出现波动，就可能导致被监控的站点被误判为无法访问。

对于这个问题，像是商业化的监控软件，例如 UptimeRobot 等都支持从多个地区来监控目标站点是否能够访问，但这些商业化软件对于使用免费计划的用户来说，基础功能限制过多，可能无法满足需求，并且订阅的价格通常也不便宜。

而 UptimeFlare 借助 Cloudflare 的强大功能，无需付费就可以实现从全球各地监控进行监控。与此同时，你也不需要单独购买服务器来部署 UptimeFlare，相比之下，将它直接部署到 Cloudflare Workers 上更加的稳定可靠。

功能

铺垫了这么久，简单介绍一下 UptimeFlare 的特性：

最多支持 50 个 1 分钟间隔的监控以及 90 天历史记录
支持指定区域的监控节点
支持 HTTP / HTTPS / TCP 端口监控，自定义 HTTP(s) 请求方法、头和主体，状态码和关键字检查
支持 Webhook 通知
支持绑定自己的域名

准备工作

标题已经提到了 UptimeFlare 需要部署到 Workers，因此你只需要准备：

一个 GitHub 账号用于存放仓库以及运行 Actions 构建到 Workers
一个 Cloudflare 账号用于部署 UptimeFlare

搭建

创建仓库

来到 UptimeFlare 的官方仓库，点击右上角的 “Use this template”，将官方仓库作为模板创建一个新的仓库

接着给仓库命名，可以直接叫 UptimeFlare，如果你不希望站点的监控配置对外暴露，那么可以将这个仓库设置为 Private 私有。

但需要注意的是，私有仓库运行 Actions 每个月只有 2000 分钟的额度，如果你私有库非常多的话需要注意一下用量。

创建 Token

通过 Cloudflare 的 API Token 可以让 Actions 构建后自动上传到 Cloudflare Workers 和 Pages，免去繁琐的手动上传操作。

来到 Cloudflare 设置页面，选择 “API Token”，点击右侧的 “Create Token”

下方的模板选择 “Edit Cloudflare Workers”

接着将账号和区域设置为所有，方便后续操作（如果你比较注重安全，也可以按照实际需求选择）

创建完成后会显示 API Token，需要立刻保存下来，离开这个页面后将无法再次查询。

添加 Token

完成 Token 的创建后，还需要将其填写到 GitHub 中

切记千万不要直接填写到 Actions 的配置文件 deploy.yml 中，这样会导致直接明文显示 API Token，是一个非常危险的操作。

正确操作应该是来到 “Settings” 中找到 Actions，在里面设置一个 secret

Name 为 CLOUDFLARE_API_TOKEN，Secret 就是刚才复制的 API Token

这样操作之后， deploy.yml 文件中只会显示 secrets.CLOUDFLARE_API_TOKEN，在运行时会自动进行替换并隐藏。

配置

在仓库的根目录下，有个 uptime.config.ts 文件，所有的配置都在这个文件中定义

详细配置可以参照示例文件的注释修改，下面简单介绍一下各个部分的作用：

pageConfig: 修改站点的标题以及导航栏
workerConfig: 配置监控项以及通知
maintenances: 展示维护信息

pageConfig

title 为站点的标题
links 为导航栏的链接，数组中的每一个对象对应一个链接

const pageConfig: PageConfig = {
  title: "lyc8503's Status Page",
  links: [
    { link: 'https://github.com/lyc8503', label: 'GitHub' },
    { link: 'https://blog.lyc8503.net/', label: 'Blog' },
    { link: 'mailto:me@lyc8503.net', label: 'Email Me', highlight: true },
  ],
}

workerConfig

在 monitors 中配置监控项

id 需要唯一
name 为展示的名字
method 与 target 则是监控的方式与目标
checkProxy 可以设置为 wnam enam sam weur eeur apac oc afr me 中的任意一个来实现指定区域监控

monitors: [
  {
    id: 'foo_monitor',
    name: 'My API Monitor',
    method: 'GET',
    target: 'https://www.google.com',
    checkProxy: 'worker://apac'
  },
  {
    id: 'test_tcp_monitor',
    name: 'Example TCP Monitor',
    method: 'TCP_PING',
    target: '1.2.3.4:22'
  }
],

在 notification 中配置通知，推荐直接使用 Webhook 来进行通知，比较便捷，无需另外部署 Apprise。

当然了，通知的配置不是必须的，如果你不需要通知的话可以直接将其删除。

notification: {
  webhook: {
    url: 'https://api.telegram.org/bot123456:ABCDEF/sendMessage',
    payloadType: 'param',
    payload: {
      chat_id: 5678,
      text: '$MSG'
    }
  }
}

maintenances

维护信息一般情况下是用不到的，但不能将它直接删除，否则部署的时候会失败，将它设置为空数组即可

const maintenances: MaintenanceConfig[] = [];

部署

如果你对 Git 操作不了解的话，可以直接在网页上编辑 uptime.config.ts，编辑完成后点击右上角的 “Commit” 提交。

提交后会自动触发 GitHub Actions 开始部署，等待几分钟后，应该就能看在 Cloudflare 看到 uptimeflare 与 uptimeflare_worker 了。

此时访问自带的 <name>.pages.dev 域名就能进入 UptimeFlare 了。

如果你需要自定义域名也非常简单，将它添加上方的 uptimeflare 这个 Pages 中即可（注意不要添加到 Workers 去了）

UptimeFlare：免费开源的多区域网站状态监控 轻松部署到 Workers ​

前言 ​

功能 ​

准备工作 ​

搭建 ​

创建仓库 ​

创建 Token ​

添加 Token ​

配置 ​

pageConfig ​

workerConfig ​

maintenances ​

部署 ​