Dumza vs Uptime Kuma

Kuma 没法告诉你,Kuma 自己什么时候宕机了

这是它唯一做不到的事。Kuma 是款不错的软件:MIT 协议开源,支持的监控类型比我们多,通知渠道列表在同类产品里也是最全的。但它运行在你自己的机器上,和它监控的对象共享同一个故障域——一旦那台机器掉线,你的监控也跟着一起消失。

什么情况下 Kuma 仍是更好的选择

对很多场景来说,自建本身就是重点,这一点我们不会试图说服你放弃。如果你的检测请求不能离开内网,或者需要 TCP、ping、DNS、Docker 监控,又或者现在就要用 Discord 接收告警,这些 Kuma 都能做,我们做不到。Dumza 只检测 HTTP 和 HTTPS 端点,仅此而已。

我们在你的基础设施之外运行同样的检测,而且这台机器永远不需要你去打补丁。

并排对比

功能Uptime KumaDumza
价格免费,但服务器成本要你自己承担有免费版,付费版从 $7/月起
服务器由谁运维你自己我们来
部署方式用 Docker 或 npm 部署,之后还要自己更新和备份数据卷注册账号,粘贴一个 URL 即可
监控数量不限量,取决于你的硬件能撑多少免费版 10 个,$7 版 20 个,$19 版 100 个,$39 版 500 个
监控类型HTTP、TCP、ping、DNS、Docker、push、数据库等多种类型仅支持 HTTP 和 HTTPS
检测间隔自己设置,只要机器扛得住,想多快就多快免费版 5 分钟,$7 版起可到 1 分钟
多地区检测需要手动搭建,自己运行多个实例内置支持
如果监控系统本身宕机了不会有任何提示空档会被记录下来,标记为“工作节点离线”,不会计入你的正常运行时间统计
告警渠道通过 Apprise 支持 90 多种服务商,每一个都要手动配置邮件、webhook、Telegram、Slack,每个账号只需连接一次。暂不支持 Discord
状态页内置支持内置支持,并自带自动生成的故障历史和订阅者邮件通知

最近一次核对 Uptime Kuma 1.23 与 2.x 的信息:2026 年 8 月。

导入后会保留什么

在 Kuma 1.23 中,导出功能位于 设置 → 备份 → 导出。把这个 .json 文件喂给导入窗口,系统会先给你一个可编辑的预览,之后才会真正创建监控。2.x 版本移除了备份界面,所以在 2.x 上,用 uptime-kuma-api 提取出的监控数组同样可以使用。

HTTP 检测项的名称、URL 和检测间隔都会完整保留。如果间隔低于你所在套餐的下限,系统会自动调高而不是直接拒绝,所以一个 20 秒的检测会变成 1 分钟,而不会导致整个文件导入失败。

任何我们跑不了的监控都会按名称列出来,让你清楚哪些被留下了:TCP、ping、DNS、push 和 Docker 监控,使用 GET、HEAD、POST 以外方法的请求,以及“反向”(upside-down)模式。认证请求头和请求体同样不会被带过来,因为备份文件是在你的浏览器里解析的,从不会上传给我们。这些检测会被导入,但在你重新填入凭证之前会一直失败。

你所在套餐的监控数量上限依然有效。把 40 个监控导入免费账号,你会得到其中 10 个,以及剩下 30 个的清单。

两者并行跑一周看看

完全没什么能阻止你让 Kuma 继续盯着同样这些 URL,同时让 Dumza 从你的网络之外做检测。如果两者对某个服务是否在线出现分歧,那正是最值得关注的地方。免费版,无需信用卡。