Uptime Kuma 自托管监控：一条 Docker 命令能换来什么

它解决的是哪一类监控需求

Uptime Kuma 瞄准的是那些不想依赖 SaaS 监控服务的用户。作者在 README 的 Motivation 部分写明，他在寻找类似 Uptime Robot 的自托管工具，但没找到合适的，于是自己写了一个。它解决的问题很具体：你有一台服务器，想持续检查自己的网站或 API 是否在线，并在出问题时收到通知，同时还想对外发布一个状态页面。这类需求用商业服务能做，但数据落在别人手里，而且按探针数量收费。Uptime Kuma 把整个监控栈塞进一个 Docker 容器，数据留在你的机器上。它面向的是个人站长、小型团队，以及那些对监控数据隐私有要求的工程师。

检查类型与通知渠道的实际覆盖面

README 列出的检查类型包括 HTTP(s)、TCP、HTTP(s) Keyword、HTTP(s) Json Query、Websocket、Ping、DNS Record、Push、Steam Game Server 和 Docker Containers。这个列表覆盖了大多数基础监控场景，但注意它没有提到分布式探针。所有检查都从运行 Uptime Kuma 的那台服务器发起。通知方面，它支持 Telegram、Discord、Gotify、Slack、Pushover、Email (SMTP)，以及 90 多种其他服务。这个数字来自 README 的链接，具体列表在 src/components/notifications 目录下。对于个人使用，这个覆盖面已经足够，但如果你想接入内部自建的告警系统，需要确认是否在支持列表里。

工作机制：WebSocket 与单文件数据存储

从 README 的 Motivation 可以看出，作者特意选择用 WebSocket 配合 SPA 而不是 REST API 来构建前端交互。这意味着监控状态的变化可以实时推送到浏览器，不需要频繁轮询。数据存储方面，Docker 部署时数据保存在 /app/data 目录，非 Docker 安装时由 server/server.js 管理。README 没有详细说明数据库类型，但根据仓库结构，它使用 SQLite 的可能性较大，这一点无法从当前材料完全确认。值得注意的限制是 README 明确警告 NFS 文件系统不受支持，要求映射到本地目录或 volume。这对使用 NAS 或网络存储的用户是一个硬约束。

部署路径：Docker 与非 Docker 的取舍

官方推荐的部署方式是 Docker Compose。README 给出了三条命令：创建目录、下载 compose.yaml、然后 docker compose up -d。容器默认监听 3001 端口，并且绑定到所有网络接口。如果你想只对 localhost 开放，需要手动加上 -p 127.0.0.1:3001:3001。非 Docker 安装要求 Node.js 不低于 20.4、Git 和 pm2，步骤是 git clone、npm run setup，然后用 node server/server.js 或 pm2 start 启动。这里有个明显的分叉：Docker 方式适合不想管理 Node 环境的用户，非 Docker 方式适合已经用 pm2 管理进程的服务器。但非 Docker 方式明确不支持 FreeBSD、OpenBSD、NetBSD，也不支持 Replit 或 Heroku。如果你用的是这些平台，只能另寻他路。

更新与维护成本

README 把更新说明放在单独的 Wiki 页面，没有在 README 中直接给出命令。从仓库的活跃度看，最近一次推送是 2026 年 8 月 22 日，版本号到 2.5.3，说明项目维护是持续的。但更新方式需要你自己去查 Wiki，这意味着升级不是零操作。对于 Docker 部署，通常需要拉取新镜像并重建容器，但 README 没有给出具体命令。对于 pm2 部署，更新可能涉及 git pull 和重新运行 setup。另一个维护点是通知服务的配置，90 多种服务的接入意味着每个服务的 API 都可能变化，但这不是 Uptime Kuma 自身的问题。许可证是 MIT，这意味着你可以自由修改和商用，但需要保留版权声明。

限制与失败模式

最直接的限制是存储：NFS 不被支持。如果用户按照习惯把数据目录挂载到 NAS 上，可能会遇到数据库损坏或写入失败。第二个限制是检查的单一来源。所有监控请求都从 Uptime Kuma 所在的服务器发出，如果这台服务器本身网络有问题，所有检查都会误报。对于个人网站来说，这可能可以接受，但如果你监控的是多个地域的服务，单点检查无法反映真实可用性。第三个限制是 20 秒的检查间隔。README 提到这是默认间隔，但没有说明是否可以调短。对于需要秒级告警的场景，这个间隔可能太长。最后，作者在 README 中明确表示不通过邮件提供支持，遇到问题只能去 GitHub Issues 或 subreddit 搜索。

替代方案：Uptime Robot 与 statping 的差异

README 的 Motivation 部分直接提到了两个替代品：Uptime Robot 和 statping。Uptime Robot 是商业 SaaS，它的核心差异在于托管探针，你不需要自己维护服务器，但数据不在你手里。statping 是另一个自托管工具，但作者认为它不稳定且不再维护。Uptime Kuma 与它们的本质区别在于：它把监控软件本身变成了一个 Docker 容器，而 statping 需要你手动管理 Go 环境。与 Uptime Robot 相比，Uptime Kuma 没有多区域探针，但你可以完全控制数据。如果你需要多区域监控，Uptime Robot 这类服务是更合适的选择，但如果你能接受单点检查，Uptime Kuma 提供了更低的门槛和更高的数据自主性。

界面与状态页面的实际价值

README 强调 UI 是 Fancy、Reactive、Fast，并支持多语言。状态页面可以创建多个，并且可以映射到特定域名。这意味着你可以为不同的客户或项目生成独立的公开状态页。对于个人开发者，这是一个低成本展示服务可用性的方式。但要注意，状态页面的数据来自 Uptime Kuma 自身的检查结果，如果检查源有问题，状态页也会显示错误。此外，2FA 支持是针对登录后台的，不是针对状态页的。状态页本身是公开的，所以不要在上面放敏感信息。这个功能的价值在于，它把监控数据和对外展示整合在同一个工具里，省去了单独搭建状态页系统的麻烦。

编辑结论

Uptime Kuma 适合那些不想把监控数据交给第三方、又希望界面现代且配置简单的个人开发者或小团队。它不适合需要分布式探针、复杂告警路由或严格 SLA 报告的企业场景，因为其检查默认从单一服务器发起，且 README 明确不支持 NFS 文件系统。部署前应先确认你的存储是本地目录或 Docker volume，并检查 Node.js 版本是否不低于 20.4（非 Docker 安装时）。如果监控目标涉及多个地理位置，建议先验证单点检查能否满足需求，否则应考虑自带多区域探针的商业方案。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes