Uptime Kuma 是一个自建的站点可用性监控面板：填一个网址，它按固定间隔去访问，把每次结果画成一条心跳色块，掉线就发通知。前端 Vue、后端 Node，数据落 SQLite。这篇在 Windows 上从源码构建起服务，建了一个监控项，把两次真实探测的结果记下来。

npm ci 被拦，换独立缓存 53 秒装完

npm ci                          7 分 44 秒后失败（safe-delete 拦下缓存清理）
npm install --cache 新目录       changed 72 packages in 53s
node_modules                     501 MB，857 个顶层目录
源码包                           2,280,392 字节（2.1.3 tag 的 zip）

第一次用 npm ci 装到一半被这台机器上的删除拦截工具打断，报 SAFE_DELETE_BULK_CONFIRM_REQUIRED，指向 npm 缓存里的临时目录。换成独立缓存目录再跑 npm install，只补了 72 个包，53 秒收工。包已经落地但二进制链接没建，后面单独重建了一次。

构建 21 秒，主包 2119.86 kB

npm run build                    21.1 秒
assets/index-*.js                2119.86 kB（brotli 后 459.61 kB）
assets/index-*.css               315.93 kB（brotli 后 34.63 kB）
assets/zh-CN-*.js                107.79 kB（brotli 后 35.59 kB）
assets/PingChart-*.js            179.84 kB（brotli 后 55.41 kB）

前端是 Vue 打包出来的单页应用，主包两兆出头，压缩后传到浏览器 460 kB 左右。语言包是独立 chunk，中文那份 107.79 kB，所以只在切到中文时才下载。图表组件也拆出去了，首屏不会带上。

缺 sqlite3 原生绑定，rebuild 才起得来

启动报错   Cannot find module 'napi-v6-win32-x64/node_sqlite3.node'
修复       npm rebuild @louislam/sqlite3
过程       node-pre-gyp 下载 napi-v6-win32-x64-unknown.tar.gz 并解出 1 个 .node

这个包用的是 @louislam/sqlite3，原生模块靠 node-pre-gyp 在安装时下载预编译二进制。前面 npm 中断导致这一步没跑，Node 起来就报找不到 .node 文件。补一条 rebuild 就好，不用装 Visual Studio 编译链。

首次启动先选数据库，再建账号

步骤页面要填什么
1/setup-database选 MariaDB/MySQL 或 SQLite，本次选 SQLite
2初始化中显示 Setting up the database，等它建表
3/setup用户名 + 两遍密码，建管理员
4/dashboard直接进面板，没有邮箱验证这一步

2.1.3 比老版本多了一步选数据库，选完会写一个 data/db-config.json，之后启动就按这个文件连。SQLite 模式下建库完成是 kuma.db 61,440 字节，29 张表。整个面板的中文是内置的，右上角下拉切语言即可。

加监控只要名称和 URL

Monitor Type          HTTP(s)
Friendly Name         本站首页
URL                   http://127.0.0.1:3020/
Heartbeat Interval    60 秒
Retries               0（失败一次就算掉线）
Request Timeout       48 秒

表单左侧是 General，右侧是 Notifications 与 Proxy，没配通知时那两栏显示 Not available。类型下拉里还有 TCP 端口、Ping、DNS、关键字、Docker 容器这些，本次只用 HTTP(s)。间隔单位是秒，填 60 表示每分钟探一次，最低可以压到 20 秒。

两次心跳：一条 200，一条 502

id 1   status=1（Up）    200 - OK                           ping 10 毫秒
id 2   status=0（Down）  Request failed with status code 502  ping 为空

第一条是正常探测，详情页显示 Up、Response 10 毫秒、24 小时可用率 100%。第二条出现在服务进程被关掉之后，面板上立刻变成红色 Down，事件表里写成 502。这个 502 不是目标站点返回的，是前端调接口时后端已经不在，所以记录里 ping 是空的。也就是说：面板本身挂了，最后一条心跳会变成一个假故障。

数据都在一个 61 KB 的文件里

项目实测值
数据库data/kuma.db，61,440 字节
表数量29
监控项1 条（本站首页，间隔 60 秒）
心跳记录2 条：1 条 Up、1 条 Down
平均响应10.0 毫秒

备份就是拷 data 目录，没有外部依赖。注意到心跳表只存一条记录的 ping 值，掉线那次是 NULL，统计平均响应时会自动跳过，这一点在做容量估算时用得上。

实测范围：Windows 10 22H2（10.0.19045.6466） / Uptime Kuma 2.1.3 / Node 22.22.2 / SQLite / 2026-10-22。通知渠道、状态页、Docker 监控、多用户权限都没有验证，不作结论。